On Feb 1, 2013, at 3:59 AM, Geert Janssens <[email protected]> wrote:
> On 31-01-13 22:52, John Ralls wrote: >> 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. > Right, I used some confusing commit notation. I wasn't aware of the typical > notation for cherry-picking vs merging. Glad we cleared this up. > > I have run the test as Buddha Buck suggested and it does work indeed as I had > hoped. Git will always go back only until the most recent common ancestor. So > if the merge conflict between C and D is resolved in E, this same merge > conflict will no longer pop up when trying to merge G and H in I. >>>> 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. > This issue is exactly the same between merging or cherry-picking, so choosing > a merge strategy over a cherry-pick strategy for our future process won't > make this harder. In both cases, the longer the two branches are diverged the > more chance there will be for a merge conflict when a certain commit is to be > "copied" from one branch to another. Um, no, a cherry-pick has only one parent. See for example [1] which I cherry picked from [2]. If D is cherry-picked into E then the conflicts *will* have to be merged again at H. That was Yawar's point about the conflicts in trying to merge 2.4 into trunk: Because all of the cherry-picks carry no history with them (and svn would have eaten it anyway if we'd tried to merge, it has no concept of multi-parent commits), git had to go back to the branch point and couldn't recognize any common commits since. >> 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. >> > Absolutely. The extreme case being if commit D is not even wanted on the > trunk branch (like a product version number increase for example). It would > still have to be merged. You could choose to do it on commit D, resulting in > an empty commit with two parents, or you can wait for commit H, and make sure > the changes from commit D are reverted during the later merge. > > For developers interested in the experiment, you can clone my testing > repository on github (https://github.com/gjanssens/testing.git) and look at > the development and stable branches. For those unfamiliar with Github, the visualization is at https://github.com/gjanssens/testing/network Regards, John Ralls [1] http://git.gnome.org/browse/glib/commit/glib/gtimezone.c?h=glib-2-34&id=04aead8a42f4964bccd9f33de9056c9e567c8b16 [2] http://git.gnome.org/browse/glib/commit/glib/gtimezone.c?id=86a8ec047e43e5767604bea5d0b31b65165a8c94 _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
