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.
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'. On Thu, Jan 31, 2013 at 3:54 PM, Geert Janssens <janssens-ge...@telenet.be> wrote: > On 31-01-13 20:40, John Ralls wrote: >> >> On Jan 31, 2013, at 10:22 AM, Geert Janssens <janssens-ge...@telenet.be> >> wrote: >> >>> On 31-01-13 18:26, John Ralls wrote: >>>> >>>> On Jan 31, 2013, at 8:52 AM, Yawar Amin <yawar.a...@gmail.com> wrote: >>>> >>>>> Hi John, >>>>> >>>>> On 2013-01-31, at 11:15, John Ralls <jra...@ceridwen.us> wrote: >>>>> >>>>>>> [...] >>>>>>> >>>>>> I think that you guys have a misunderstanding about how merging works. >>>>>> Try merging 2.4 back into trunk. >>>>>> When I did just now, 4 files merged successfully, the rest have >>>>>> conflicts. One might be able to do better by playing with the merge >>>>>> options. >>>>>> I'm not going to spend the time. >>>>>> >>>>>> Merging a commit doesn't just look at the files touched by that >>>>>> particular commit, it looks at every difference between the trees of the >>>>>> source commit and the target (i.e., the current branch). >>>>>> >>>>>> Cherry-pick exists for a reason. >>>>> >>>>> I think we have to look at this from the other end: 2.4 is not merging >>>>> cleanly into trunk precisely _because_ of all the >>>>> cherry-picking/backporting >>>>> that's been going on. >>>>> >>>>> If you create a new git branch, e.g. 2.6, from trunk, and don't allow >>>>> any backported patches on it, I'd say you'd have a much better chance of a >>>>> clean merge. >>>> >>>> If you create a new git branch from trunk and don't make any changes >>>> (remember, backports are the only allowed changes on a release branch), >>>> then >>>> of course it will merge cleanly: It won't have any changes, so the merge >>>> will be a no-op. >>>> >>>> Geert corrected me about when 2.4 was branched, so we can easily >>>> demonstrate this using 2.4.3: >>>> $ athena:/Users/john/gnucash> git merge 2.4.3 >>>> Already up-to-date! >>>> >>>> Kinda misses the point about having a stable branch, though. >>>> >>>> Regards, >>>> John Ralls >>>> >>> I'm under the impression we are not talking about the same configuration. >>> For me the premise of this discussion was to have a stable branch and a >>> development branch. Bugfixes are done on the stable branch, new features or >>> bug fixes too drastic for stable happen on development. To get the bugfixes >>> from stable to development the stable branch is regularly merged into >>> development. Regularly being the key here to avoid merges that become too >>> complicated. In this scenario not "backports" happen from development to >>> stable, but bugfixes still get forward-ported to development. >>> >>> Perhaps some drawings may help. Consider this starting point: >>> >>> - A - B - C (development) >>> \ >>> ----- D (stable) >>> >>> A is the last common commit between stable and development. Development >>> has been going in for a while, resulting in commits B and C on that branch. >>> Then a bugfix commit D is created on stable (not on development). >>> >>> Bugfixes should also go into development, so at this point the stable >>> branch is to be merged into development. First step of the merge: create a >>> temporary branch on stable (we want stable to remain an independent branch >>> after the merge: >>> >>> - A - B - C (development) >>> \ >>> ----- D (stable, tmp-branch) >>> >>> Then merge this tmp-branch into development, possibly fixing any merge >>> conflicts. These merge conflicts would have been there in the >>> backport/cherry-pick scenario as well, so nothing new. >>> >>> - A - B - C - D' (development, tmp-branch) >>> \ / >>> ----- D - (stable) >>> >>> The tmp-branch is discarded now, it only served for the merging. More >>> development continues on development and at some point another bugfix lands >>> on stable: >>> >>> - A - B - C - D' - E - F (development) >>> \ / >>> ----- D ---------- G (stable) >>> >>> Same dance. Setup temporary branch, merge it into trunk potentially >>> resolving conflicts. Given commit D is already merged, I assume that git >>> will only take the differences in commit G into account for the merge, >>> resulting in this new picture: >>> >>> - A - B - C - D' - E - F - G' (development) >>> \ / / >>> ----- D ---------- G - (stable) >>> >>> It looks pretty much like the inverse of our current backport strategy >>> with the same merge conflict issues as cherry-picking. The big advantage in >>> this process is that the git history shows you in one glance which bugfixes >>> are not merged into development yet. >>> >>> Note that refinement is possible by requiring separate branches for most >>> development, that then have to be merged into stable or development after >>> review. Kind of re-adds the AUDIT procedure that currently is no longer in >>> use. >>> >>> Possibly this process is flawed in other ways I'm missing. I'm happy to >>> learn about them. >> >> This breaks down when B and C affect the same code that D does. Obviously >> you resolve those conflicts in favor of the development branch when you >> merge D. No problem, right? Well, you have to resolve them again for every >> subsequent merge. That snowballs into "too hard" after a few dozen changes, >> as my merge of 2.4 into trunk demonstrated. > > Oh, boy, there's my wrong assumption. I assumed that after merging D into B > and C, git would no longer consider D's changes for the next merge. > > If it is as you say, my proposed method would not work at all obviously. > > Geert > > _______________________________________________ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
