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

John Ralls jralls at
Fri Feb 1 09:54:42 EST 2013

On Feb 1, 2013, at 3:59 AM, Geert Janssens <janssens-geert at> wrote:

> On 31-01-13 22:52, John Ralls wrote:
>> On Jan 31, 2013, at 1:46 PM, John Ralls <jralls at> wrote:
>>> On Jan 31, 2013, at 1:08 PM, Buddha Buck <blaisepascal at> 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.
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.

>> 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 ( and look at the development and stable branches.

For those unfamiliar with Github, the visualization is at

John Ralls


More information about the gnucash-devel mailing list