merge -s ours question

merge -s ours question

[Jay Soffian]

Here's the scenario,

I have a muddled development branch that has a mix of local development and
upstream merges:

 upstream 1--2--3--4--5
           \     \     \
      dev   o--A--x--B--x ... Y

It took a lot of work, but I backported everything newer than A using rebase
and cherry-pick, and omitting the merges, giving me a dev' clean of merges
from upstream:

     dev'   o--A'--B' ... Y'
           /
 upstream 1--2--3--4--5
           \     \     \
      dev   o--A--x--B--x ... Y

Now it turns out that going forward, I need two development branches, one
that's based on a newer version of upstream for which the merge work was
already done in the original dev. In an ideal world I'd have this history:

upstream 1--2--3--4--5
          \           \
    dev2   \           o--o--o--o
            \
    dev1     o--o--o--o--o

And I would periodically merge dev1 into dev2 (dev2 requires the work being
done on dev1). The problem is that my backported dev' has a mix of dev1 and
dev2 and it's impossible for me to tease them apart at this point. So my plan
was to do this:


     dev'   o--A'--B' ... Y'
           /               \
 upstream 1--2--3--4--5     \
           \     \     \     \
      dev   o--A--x--B--x ... Z

Where Z is created using using "git merge -s ours dev'". Is it correct that
this should do nothing more than give me a new merge base for dev and dev'?
Then going forward I can merge from dev' to dev per usual.

Thanks,

j.

Re: merge -s ours question

[Junio C Hamano]

Jay Soffian <jaysoffian@gmail.com> writes:

> It took a lot of work, but I backported everything newer than A using rebase
> and cherry-pick, and omitting the merges, giving me a dev' clean of merges
> from upstream:
>
>      dev'   o--A'--B' ... Y'
>            /
>  upstream 1--2--3--4--5
>            \     \     \
>       dev   o--A--x--B--x ... Y

I understand that at this point "dev'" is the moral equivalent of what you
called "dev1" in the next picture.

> upstream 1--2--3--4--5
>           \           \
>     dev2   \           o--o--o--o
>             \
>     dev1     o--o--o--o--o

It is unclear what commits on dev2 branch are about in this picture.  Are
they replay of what you have on dev1?  Or are they about a feature that is
different from what dev1 does, perhaps using what dev1 have already done,
or perhaps totally independent of dev1?

If "dev1" and "dev'" are the moral equivalents, and dev2 wants to use what
dev1 did _and_ what is in updated upstream (i.e. dev2 cannot build without
either dev1 nor some of the feature/fix in "2"..."5"), then I would
probably build a history that looks like this:

                      o--o--o dev2 (builds on top of dev1)
                     /
                 .--*   merge between dev1 and upstream
                /  /
      o--o--o--o  /   dev1
     /           /
    1--2--3--4--5     upstream
  
and give a pull request to the upstream for "*" to incorporate the fully
cooked work done on dev1.

Also if "dev'" and "dev1" are the moral equivalents, then the merge "*"
above _should_ match exactly what you had at "Y" in "dev" in the original
mergy history.  So after creating "*", you may want to do a regular merge
(IOW, I don't think "-s ours" is necessary if you rebuilt "dev1" right)
between it and 'dev' to create "M" that should result in the same tree:

                 .--*   merge between dev1 and upstream
                /  / \
      o--o--o--o  /   \        dev1
     /           /     \
    1--2--3--4--5       \      upstream
     \     \     \       \
      o--A--x--B--x-..-Y--M    dev
                           \
                            o--o--o dev2'

and build "dev2'" on "dev" instead; but you probably cannot offer "dev" to
be pulled to the upstream due to the criss-cross mess (that was the whole
reason you did "dev1" in the first place), and doing so would make "dev2'"
unpullable for the same reason.  So I don't see much point in doing that
merge "M" nor keeping "dev" branch around, once you verified that "*" and
"Y" matches to make sure your rebuilt dev1 has what dev has, and it is
what dev should have looked like in the first place.

If you want to keep merging from dev1 to dev2 because dev1 is still not
ready, you might want to choose to rebase dev2 on top of dev1 instead.

Re: merge -s ours question

[Jay Soffian]

On Mon, Mar 8, 2010 at 5:57 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Jay Soffian <jaysoffian@gmail.com> writes:
>
>> It took a lot of work, but I backported everything newer than A using rebase
>> and cherry-pick, and omitting the merges, giving me a dev' clean of merges
>> from upstream:
>>
>>      dev'   o--A'--B' ... Y'
>>            /
>>  upstream 1--2--3--4--5
>>            \     \     \
>>       dev   o--A--x--B--x ... Y
>
> I understand that at this point "dev'" is the moral equivalent of what you
> called "dev1" in the next picture.
>
>> upstream 1--2--3--4--5
>>           \           \
>>     dev2   \           o--o--o--o
>>             \
>>     dev1     o--o--o--o--o
>
> It is unclear what commits on dev2 branch are about in this picture.  Are
> they replay of what you have on dev1?  Or are they about a feature that is
> different from what dev1 does, perhaps using what dev1 have already done,
> or perhaps totally independent of dev1?
>
> If "dev1" and "dev'" are the moral equivalents, and dev2 wants to use what
> dev1 did _and_ what is in updated upstream (i.e. dev2 cannot build without
> either dev1 nor some of the feature/fix in "2"..."5"),

Sorry I was unclear in my diagrams, and you guessed correctly, dev2
needs both dev1 and newer commits from upstream. So a correct "ideal"
picture would've been:

upstream 1--2--3--4--5.
          \            \
    dev2   \            o--o--o--o
            \          /
    dev1     o--o--o--o--o


Now, development will continue on all three branches, with dev2
needing changes from both dev1 and upstream. In fact, dev1 may also
periodically need changes from upstream, but for the foreseeable
future, dev1 will be based on an older version of upstream than dev2.

> then I would
> probably build a history that looks like this:
>
>                      o--o--o dev2 (builds on top of dev1)
>                     /
>                 .--*   merge between dev1 and upstream
>                /  /
>      o--o--o--o  /   dev1
>     /           /
>    1--2--3--4--5     upstream
>
> and give a pull request to the upstream for "*" to incorporate the fully
> cooked work done on dev1.

Okay. One detail I left out is that dev1 and dev2 will never go
upstream. They are forever downstream. Hopefully at some point dev1
and dev2 can be based on the same upstream commit, but for now dev2
will periodically be merging from dev1 and will remain on a newer
upstream commit than dev1. (Periodically, both dev1 and dev2 may merge
from upstream, but it will be the case that dev1 merges from an older
upstream commit than dev2.)

> Also if "dev'" and "dev1" are the moral equivalents, then the merge "*"
> above _should_ match exactly what you had at "Y" in "dev" in the original
> mergy history.  So after creating "*", you may want to do a regular merge
> (IOW, I don't think "-s ours" is necessary if you rebuilt "dev1" right)
> between it and 'dev' to create "M" that should result in the same tree:
>
>                 .--*   merge between dev1 and upstream
>                /  / \
>      o--o--o--o  /   \        dev1
>     /           /     \
>    1--2--3--4--5       \      upstream
>     \     \     \       \
>      o--A--x--B--x-..-Y--M    dev
>                           \
>                            o--o--o dev2'
>
> and build "dev2'" on "dev" instead; but you probably cannot offer "dev" to
> be pulled to the upstream due to the criss-cross mess (that was the whole
> reason you did "dev1" in the first place), and doing so would make "dev2'"
> unpullable for the same reason.  So I don't see much point in doing that
> merge "M" nor keeping "dev" branch around, once you verified that "*" and
> "Y" matches to make sure your rebuilt dev1 has what dev has, and it is
> what dev should have looked like in the first place.
>
> If you want to keep merging from dev1 to dev2 because dev1 is still not
> ready, you might want to choose to rebase dev2 on top of dev1 instead.

Okay. I think I have more work ahead of me creating '*'. I was trying
to avoid having to do that. It is actually composed of multiple merges
with some fairly complex resolutions, but maybe rerere-train and
rerere can help me here.

j.