How to handle multiple long-term branches (was Re: Notification mails for git repos)
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
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.
More information about the gnucash-devel