On Jan 31, 2013, at 1:08 PM, Buddha Buck <blaisepas...@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 _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
