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

[John Ralls]

On Feb 1, 2013, at 8:20 AM, Geert Janssens <janssens-geert at telenet.be> wrote:

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

Sorry, I was objecting to your "exactly the same between merging or cherry-picking", not proposing an alternate scenario. If we adopt your proposed flow, cherry-picks shouldn't be allowed.

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

Well, if you chose to undo whatever was in development that caused the conflict, maybe. I don't see that being a common choice. ;-)

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

I've never found a Gnome policy. Practice seems to be similar to ours, master is changed first and backports are cherry-picked onto stable branches. Feature branches are rebased back on to master rather than merged (which I dislike, because it leaves the feature branch dangling, so one can't tell if it's been merged or abandoned). Gnome switched from svn five or so years ago and I think that most of the developers still have something of an svn mindset.

I used to maintain a pair of public tracking branches for quartz with some changes that other devs weren't ready to buy into, along with a nightly merge-from-mainline (master and gtk-2-24) and build. Emmanuel Bassi yelled at me long and hard for generating too much change-mail noise, so I stopped updating it... but I also got some cooperation from the other devs and got most of the changes into mainline.

Regards,
John Ralls