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

>
> Tomi Belan <tomi.belan@gmail.com> writes:
>
> > 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 1.8.0.1.
>
> Probably it would be a good idea to bring it to the attention of people
> who have worked on it: Avery and David (cc'd).
>
> >> On Sat, Oct 13, 2012 at 3:47 PM, Tomi Belan <tomi.belan@gmail.com> 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: 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
>
> --
> Thomas Rast
> trast@{inf,student}.ethz.ch