A possible subtree split bug

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 <fabien.potencier@gmail.com> writes:

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