A possible subtree split bug

A possible subtree split bug

[Fabien POTENCIER]

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

Re: A possible subtree split bug

[greened]

Fabien POTENCIER <fabien.potencier@gmail.com> writes:

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

I'm not entirely sure that they history *should* be the same in the
presence of a merge.  It's certainly not the same history as when
the original split was done so I don't think guarantee holds.

                          -Dave