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

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

[Tomi Belan]

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

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

[Tomi Belan]

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

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

[Tomi Belan]

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.

Tomi

On Sun, Oct 21, 2012 at 11:18 PM, Tomi Belan <tomi.belan@gmail.com> 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 <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

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

[Tomi Belan]

Thanks. Here's one more bump. Avery? David?

(Apologies if my bumping is annoying -- because there's no bug
tracker, it feels like the bug will be lost in the ML archives forever
unless I keep calling attention to it. How can I help to get this
issue fixed?)

Tomi

On Mon, Dec 3, 2012 at 4:42 PM, Thomas Rast <trast@student.ethz.ch> wrote:
>
> 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

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

[Junio C Hamano]

Tomi Belan <tomi.belan@gmail.com> writes:

> Thanks. Here's one more bump. Avery? David?

Thanks for your persistence.

I am moderately dissapointed by the inaction on the subtree part so
far.  It was merged hoping that it will have more exposure to the
end-users if it were in my tree, and it obviously is gettng that,
but the people involved in the subtree part does not seem to be
holding their end of the bargain.

I am seriously considering to remove it from the contrib/ area of my
tree if we do not see any response.  The contrib/ area is not meant
to be a dumping ground for abandoned WIP.

Maybe it is a seasonal thing, just before the holiday season, but
this has been unresponded for a couple of months, not even with a
"That combination is not supported", or "Thanks for a bug report".

Grumpy.

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

[greened]

Tomi Belan <tomi.belan@gmail.com> writes:

> Thanks. Here's one more bump. Avery? David?

I don't know how this is supposed to work, unfortunately.  I'm still in
the middle of learning the code...

                       -David

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

[greened]

Junio C Hamano <gitster@pobox.com> writes:

> Maybe it is a seasonal thing, just before the holiday season, but
> this has been unresponded for a couple of months, not even with a
> "That combination is not supported", or "Thanks for a bug report".

I did finally see this message.  I totally admit that I've been pretty
absent.  It just happens that I have a ton of paid work to do and
voluteer work unfortunately comes last, after family and after paid
work.

For this bug I honestly don't know what is supposed to happen.  I'm
still learning the code.  It's a bit of a shell-script mess to be
honest, very hard to follow.  That's why it's still in contrib/
and will remain so for a while.

I am more than happy for others to jump in and help out.  I'm not a
gatekeeper.

                          -David