How to handle multiple long-term branches (was Re: Notification mails for git repos)

[Geert Janssens]

On 31-01-13 22:52, John Ralls wrote:
> On Jan 31, 2013, at 1:46 PM, John Ralls <jralls at ceridwen.us> wrote:
>
>> On Jan 31, 2013, at 1:08 PM, Buddha Buck <blaisepascal at gmail.com> wrote:
>>
>>> I believe Geert's assumption is right -- git sees D as in the history
>>> of both F and G, and won't try to remerge the A->D changes back into
>>> G'.  This should be easy enough to test, just create a new git
>>> repository, and make the appropriate set of edits to see if that's the
>>> case.
>> Hmm. You might be right about that: I was thinking of D' as a modified version of D, but that's not right (it's what happens with cherry-pick) and notating it as D' is therefore misleading, so let's rewrite the chain:
>>
>> A - B - C - E - F - G - I -  (trunk)
>> \         /           /
>>    --- D ------- H ------   (stable)
>>
>> E and I are merge branches; E has  both C and D as parents and able to generate diffs to each of them, and I has both G and H as parents.
Right, I used some confusing commit notation. I wasn't aware of the 
typical notation for cherry-picking vs merging. Glad we cleared this up.

I have run the test as Buddha Buck suggested and it does work indeed as 
I had hoped. Git will always go back only until the most recent common 
ancestor. So if the merge conflict between C and D is resolved in E, 
this same merge conflict will no longer pop up when trying to merge G 
and H in I.
>>> The problem I can see is when the A->D changes and the A->B->C changes
>>> conflict, the A->B->C changes get accepted into D', AND the D->G
>>> changes also affect the same code, so that delta can't be cleanly
>>> applied to F to get G'.
>> Restating with the new notation, the A-B-C changes are incorporated into E AND if the F-G changes also affect that code then H won't apply cleanly to get I. This might actually be OK too, because git can still track the history back to D on both legs of the merge and so may be able to limit the conflicts.
This issue is exactly the same between merging or cherry-picking, so 
choosing a merge strategy over a cherry-pick strategy for our future 
process won't make this harder. In both cases, the longer the two 
branches are diverged the more chance there will be for a merge conflict 
when a certain commit is to be "copied" from one branch to another.
> One more note on that: E may very well end up looking nothing like D because B-C may have been enough of a change that a different approach is required, but it's still necessary for it to be a multi-parent commit.
>
Absolutely. The extreme case being if commit D is not even wanted on the 
trunk branch (like a product version number increase for example). It 
would still have to be merged. You could choose to do it on commit D, 
resulting in an empty commit with two parents, or you can wait for 
commit H, and make sure the changes from commit D are reverted during 
the later merge.

For developers interested in the experiment, you can clone my testing 
repository on github (https://github.com/gjanssens/testing.git) and look 
at the development and stable branches.

Geert