Re: cherry picking and merge

From: Philip Oakley <philipoakley@iee.org>
Date: Aug 2, 2014, 16:29 UTC
Message-ID: <7CCCA1CCC7F342FA9037AAFEDCEDB53F@PhilipOakley>
In-Reply-To: <FC00A4BB-6CB9-421D-83D6-4E1AFBB4CB3C@comcast.net>

From: "Mike Stump" <mikestump@comcast.net>
Sent: Friday, August 01, 2014 11:10 PM
(part 2)

Show 27 quoted lines

> On Aug 1, 2014, at 11:57 AM, Philip Oakley <philipoakley@iee.org> 
> 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.

Show 9 quoted lines

> 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.
>

...

Show 14 quoted lines

> 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.