Skip to contentSkip to conversation

A possible subtree split bug

DISCUSSION Fabien POTENCIER 2 participants 2 messages Jun 15, 2016

lore
Share & tools
lore
#0 lore raw

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

Signature · 4 lines
Fabien Potencier
Sensio CEO - Symfony lead developer
sensiolabs.com | symfony.com | fabien.potencier.org
Tél: +33 1 40 99 80 80
#1 lore raw
Quoted 8 lines · Fabien POTENCIER

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

Quoted 5 lines

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