Re: cherry picking and merge

On Aug 1, 2014, at 11:57 AM, Philip Oakley <philipoakley@iee.org> wrote:

The problem is, users expect merge to merge.  There isn’t a user that expects it to scramble the source code, because the command is called merge, not scramble.  That word has semantics that were not invented by your project.  You cannot change the semantic of the word.  Merge has a nice mathematical definition.  Merge branch into master means, place into into master the work from that branch.  git already does this 99% correct, it is missing one corner case.

This is not a philosophical issue.  It is a definitional one.

This is irrelevant to the issue at hand.

Again, irrelevant.

Do you mean, and can’t be?  If so, you are wrong in the case at hand.  svn is an existence proof that you are wrong.

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.

branch=b master=master base=$(git merge-base $branch $master) cherry="$1"

git checkout -b cherry-$branch $base git cherry-pick "$cherry" git checkout $master git merge -s ours cherry-$branch git checkout $branch git merge cherry-$branch git branch -d cherry-$branch git cherry-pick --strategy=ours --allow-empty "$cherry" git commit --allow-empty

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’m not interested in other bugs that I didn’t state, in this email.  I don’t care about those.  Please don’t detract from fixing this issue, because you can identify other things that might not be perfect.  We attain perfection one step at a time.

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.

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.