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

John Ralls jralls at ceridwen.us
Thu Jan 31 16:46:33 EST 2013


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.

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

Regards,
John Ralls




More information about the gnucash-devel mailing list