A possible subtree split bug

[Fabien POTENCIER <fabien.potencier@gmail.com>]

Hi all,

I've encountered what I think is a bug in the subtree split command 
included in contrib.

According to the docs:

"Repeated splits of exactly the same history are
guaranteed to be identical (ie. to produce the same
commit ids).  Because of this, if you add new commits
and then re-split, the new commits will be attached as
commits on top of the history you generated last time..."

But unfortunately, that's not always the case.

I've found that if you have a commit that reverts the previous one and 
then merge a branch where those two commits did not exist, then the next 
time you split, they won't be present anymore in the split tree.

Here is a simple script that exhibits the issue:

#!/bin/sh

git init

# create a directory that is going to be split
mkdir doc
echo "TEST" > doc/README
git add doc
# commit A
git ci -a -m"first version"

# create a branch with a new commit (Z)
git co -b test
echo "TEST" > doc/README1
git add doc/README1
git ci -a -m"added README1"
git co master

# modify the README file (commit B)
echo "TEST_" > doc/README
git ci -a -m"second version"

# revert the change (commit C)
echo "TEST" > doc/README
git ci -a -m"revert second version"

# split
git subtree split --prefix="doc" --branch=TARGET

# the log will show the 3 commits as expected (including B and C)
git log --oneline TARGET

# merge the test branch
git merge -m"merged test" test

# re-split
# deleting the target as the bug prevents the split to happen correctly
git branch -D TARGET
git subtree split --prefix="doc" --branch=TARGET

# the 2 commits B and C are not in the split anymore
# the split will only show A then Z which is not the expected result
git log --oneline TARGET


Fabien

-- 
Fabien Potencier
Sensio CEO - Symfony lead developer
sensiolabs.com | symfony.com | fabien.potencier.org
Tél: +33 1 40 99 80 80