On Jan 31, 2013, at 10:22 AM, Geert Janssens <[email protected]> wrote:
> On 31-01-13 18:26, John Ralls wrote: >> On Jan 31, 2013, at 8:52 AM, Yawar Amin <[email protected]> wrote: >> >>> Hi John, >>> >>> On 2013-01-31, at 11:15, John Ralls <[email protected]> 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. Regards, John Ralls _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
