On Sun, Sep 07, 2008 at 12:34:15PM +0200, Stephen R. van den Berg wrote:
> The questions now are:
> - Would there be good reason not to record the backport/forwardport
> relationship in the additional parents of a commit?
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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
