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

[Geert Janssens]

On 01-02-13 15:54, John Ralls wrote:
(Keeping the branch image for reference)
> 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.
>
>>>>> 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.
> Um, no, a cherry-pick has only one parent. See for example [1] which I cherry picked from [2]. If D is cherry-picked into E then the conflicts *will* have to be merged again at H. That was Yawar's point about the conflicts in trying to merge 2.4 into trunk: Because all of the cherry-picks carry no history with them (and svn would have eaten it anyway if we'd tried to merge, it has no concept of multi-parent commits), git had to go back to the branch point and couldn't recognize any common commits since.
Ok, I think we're visualising different scenarios here. I was comparing 
a scenario of only cherry-picks (as we do now) against a scenario with 
only merging (only possible in pure git). Your counter example assumes a 
mixture of both: D is cherry picked, H is merged.

And even then whether or not you'd have to resolve the merge conflict a 
second time also depends on what conflict resolution you chose the first 
time.

I have added some experiments to my testing trees for additional 
scenarios that were revealing to me.

My final conclusion would be (and your counter example nicely 
illustrates this): in a pure git environment, cherry-picking has the 
potential to create more merge conflicts than a properly executed merge 
strategy, exactly because cherry-picking doesn't have the same rich 
history available to make smart conflict resolution decisions.

Let me also note that sometimes cherry-picking may be the only option 
(for example if you accidentally added a commit to the wrong branch, the 
branch that is usually the target of merges, not the source). In that 
case history can be restored by performing a merge immediately after the 
cherry-pick operation from the branch that received the cherry-picked 
commit to the branch that commit was originally wrongly committed.

By the way, John, you refer to commits you pushed to the glib git 
repository. What policy is used by the glib developers to handle 
multiple maintained versions  ?
>
>>> 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.
> For those unfamiliar with Github, the visualization is at https://github.com/gjanssens/testing/network
Heh, that would include me. I didn't know this...

Geert