Another bump. I reported this back in October, but there hasn't been
any response yet...

Note that the bug is still present in git


On Sun, Oct 21, 2012 at 11:18 PM, Tomi Belan <> wrote:
> This probably got lost in the mail. Could somebody familiar with
> git-subtree take a look?
> Tomi
> On Sat, Oct 13, 2012 at 3:47 PM, Tomi Belan <> wrote:
>> Hello folks,
>> I think I might've found a bug in git-subtree: I have a repository
>> containing a directory "foo". I'd like to use its code in other
>> projects, so I want to split it off into its own repository with
>> git-subtree. But it doesn't work as it should. I found out that long
>> ago, my repository contained an unrelated directory also called "foo"
>> which has since been deleted.
>> Steps to reproduce (after installing git-subtree from contrib):
>> git init repo
>> cd repo
>> mkdir foo; touch foo/v1
>> git add -A .; git commit -m v1
>> rm -rf foo; touch v2
>> git add -A .; git commit -m v2
>> mkdir foo; touch foo/v3
>> git add -A .; git commit -m v3
>> git subtree split -P foo -b splitfoo --annotate="split "
>> What should happen: Either (A) splitfoo only contains "split v3", or
>> (B) splitfoo contains "split v1" and "split v3"
>> What happens instead: The parent of "split v3" is "v2", so splitfoo's
>> full history is: "v1" -> "v2" -> "split v3".
>> Git version:
>> Bonus questions:
>> - which is the intended behavior, (A) or (B)?
>> - if it's (B), how do I convince git-subtree to do (A) once this bug
>> gets fixed? (I might be getting too far ahead of myself here...)
>> Tomi
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to