Re: [RFC] cherry-pick using multiple parents to implement -x

On Sun, Sep 07, 2008 at 12:34:15PM +0200, Stephen R. van den Berg wrote:

Parents mean something different than just a link. If A is a parent of B, then that implies that at point B, we considered all of the history leading up to B (including A), and arrived at a certain tree state.

But cherry-picking means we looked at just A and used it to find a certain tree-state. It says nothing about anything that came _before_ A.

So imagine this history:

A--B--C <-- master
 \
  D--E--F <-- side branch

Now let's say we want to cherry-pick E. If we mark the cherry-picked commit as a parent, we get:

A--B--C--E' <-- master
 \      /
  D----E--F <-- side branch

Now let's say we want to merge the branches. What's our merge base? Without your proposal, it is A, but now it is actually E. So doing a three-way merge between E' and F with base E, it will look like our master branch _removed_ the change from D which is still present in F. And in a 3-way merge if one side removes something but the other side leaves it untouched, then the result removes it.

So the merge result is bogus, as it is missing D.

I'm including a quick script below which creates this situation (it may need tweaking to run on your system, but hopefully you get the point).

-Peff

-- >8 -- #!/bin/sh -ex

rm -rf repo

change() {
  perl -pi -e '/^'$1'$/ and $_ .= "changed $_"' words &&
  git commit -a -m $1 &&
  git tag $1
}

mkdir repo && cd repo && git init cp /usr/share/dict/words . && git add words && git commit -m initial change A change B change C git checkout -b other A change D change E change F git checkout master git cherry-pick -n E tree=`git write-tree` commit=`echo cherry pick | git commit-tree $tree -p HEAD^ -p E` git update-ref HEAD $commit