From: Philip Oakley Date: Sat, 02 Aug 2014 16:29:31 GMT Subject: Re: cherry picking and merge Message-ID: <7CCCA1CCC7F342FA9037AAFEDCEDB53F@PhilipOakley> In-Reply-To: From: "Mike Stump" Sent: Friday, August 01, 2014 11:10 PM (part 2) > On Aug 1, 2014, at 11:57 AM, Philip Oakley > wrote: >> For some central control use styles, the ideas behind _distributed_ >> version control are anathema and (Git) just grinds away at the >> policies that are expected. > ... >> of the 'relativity' that comes with being distributed - truth has to >> give way to a web of trust). Also the artefacts that Git validates >> are at a different level of abstraction i.e. the whole project as a >> commit, rather than just a few/one file at a time. > > Ah, so that gives me an idea. [ pause ] If we try the cherry-pick as > retroactively creating a feature branch, cherrying into that, then > merge unconditionally so that no change happens that into trunk (thus > killing those conflicts), and then git merge that feature branch into > branch then it all works perfectly. See, another existence proof that > you are wrong, this time with git itself. > > It was 13 lines of code, so, apparently, it is possible and easy to > do, in git. Now, we just want the cherry-pick to create a temporary > cherry branch, cherry the pick into it, merge and drop into trunk and > merge into branch… > > I tested with the below and it worked just fine. Things to clean up, > we want the meta data on the cherry on the merge commit, but, you get > the idea. > I've annotated some of the bits to make sure we are on the same wavelength as to what this does... > branch=b > master=master > base=$(git merge-base $branch $master) > cherry="$1" # not quite sure where this commit is located relative to > either $branch or $master > # create a new branch, starting at base, for our cherry picked commit > git checkout -b cherry-$branch $base > git cherry-pick "$cherry" # which also commits onto our cherry pick > barnch > git checkout $master > git merge -s ours cherry-$branch # "mark/remember" the cherry branch, > its fix and it's base point, but don't actualy use it here on $master > git checkout $branch > git merge cherry-$branch # bring the 'fix' into $branch > git branch -d cherry-$branch # remove the fix branch that started at > $base - branches are ephemeral anyway. # still on $branch, which already has the change merged in (Git style) ? > git cherry-pick --strategy=ours --allow-empty "$cherry" # check its > all already included? > git commit --allow-empty > Does my annotation match your understanding? It wasn't clear to me where $1 had been hiding previously, nor why the common fix didn't use a "merge -s ours cherry-$branch" in both cases - that maybe my misunderstanding about how your workflow goes. > I tested that with two cherries with further changes on master to > ensure that it works for more than a single one, no problem. Wow, > even tried a merge of master back into b, and it worked just fine, no > conflicts, yet, all the code was jammed up together nicely. > > So, if you wish to continue your position, please explain why it can’t > get this better, given the existence proof above of it working better > in git. > ... > I have two possible conflict fixups in the above. In my case (I have > a specific patch in gcc-land i wanted to cherry), those fixups were > trivial (no conflicts). When they are trivial, I don’t care much that > there were two of them. When non-trivial, well, I’m resigned to the > idea that I have to explain what is going on. > >> Selecting a compatible workflow is a problem of usage, > > Not when the workflow is mandated on you to work around trivial little > bugs that can be fixed but for which the author’s don't even > comprehend the bug. > >> rather than a problem in Git. > -- Philip.