Re: [BUG?] git-subtree behavior when the -P tree is removed and recreated

>
> 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: 1.7.12.2
>
> 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