On Jan 31, 2013, at 1:46 PM, John Ralls <[email protected]> wrote: > > On Jan 31, 2013, at 1:08 PM, Buddha Buck <[email protected]> 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. Regards, John Ralls _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
