merge -s ours question

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.

Jay Soffian <jaysoffian@gmail.com> writes:

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

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.

On Mon, Mar 8, 2010 at 5:57 PM, Junio C Hamano <gitster@pobox.com> wrote:

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.

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

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.