Re: merge -s ours question

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 8, 2010, 22:57 UTC
Message-ID: <7vhboql8uu.fsf@alter.siamese.dyndns.org>
In-Reply-To: <76718491003081426j4329e322we91fc6fe13f2d03@mail.gmail.com>

Jay Soffian <jaysoffian@gmail.com> writes:

Show 9 quoted lines

> 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.

Show 5 quoted lines

> 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.