Re: merge -s ours question

[Jay Soffian <jaysoffian@gmail.com>]

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.