On Feb 1, 2013, at 8:20 AM, Geert Janssens <[email protected]> wrote:
> On 01-02-13 15:54, John Ralls wrote: > (Keeping the branch image for reference) >> 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. >>> 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. > Ok, I think we're visualising different scenarios here. I was comparing a > scenario of only cherry-picks (as we do now) against a scenario with only > merging (only possible in pure git). Your counter example assumes a mixture > of both: D is cherry picked, H is merged. > Sorry, I was objecting to your "exactly the same between merging or cherry-picking", not proposing an alternate scenario. If we adopt your proposed flow, cherry-picks shouldn't be allowed. > And even then whether or not you'd have to resolve the merge conflict a > second time also depends on what conflict resolution you chose the first time. Well, if you chose to undo whatever was in development that caused the conflict, maybe. I don't see that being a common choice. ;-) > > I have added some experiments to my testing trees for additional scenarios > that were revealing to me. > > My final conclusion would be (and your counter example nicely illustrates > this): in a pure git environment, cherry-picking has the potential to create > more merge conflicts than a properly executed merge strategy, exactly because > cherry-picking doesn't have the same rich history available to make smart > conflict resolution decisions. > > Let me also note that sometimes cherry-picking may be the only option (for > example if you accidentally added a commit to the wrong branch, the branch > that is usually the target of merges, not the source). In that case history > can be restored by performing a merge immediately after the cherry-pick > operation from the branch that received the cherry-picked commit to the > branch that commit was originally wrongly committed. > > By the way, John, you refer to commits you pushed to the glib git repository. > What policy is used by the glib developers to handle multiple maintained > versions ? I've never found a Gnome policy. Practice seems to be similar to ours, master is changed first and backports are cherry-picked onto stable branches. Feature branches are rebased back on to master rather than merged (which I dislike, because it leaves the feature branch dangling, so one can't tell if it's been merged or abandoned). Gnome switched from svn five or so years ago and I think that most of the developers still have something of an svn mindset. I used to maintain a pair of public tracking branches for quartz with some changes that other devs weren't ready to buy into, along with a nightly merge-from-mainline (master and gtk-2-24) and build. Emmanuel Bassi yelled at me long and hard for generating too much change-mail noise, so I stopped updating it... but I also got some cooperation from the other devs and got most of the changes into mainline. Regards, John Ralls _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
