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

John Ralls jralls at
Thu Jan 31 16:52:57 EST 2013

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

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.

John Ralls

More information about the gnucash-devel mailing list