threads / bug / 31800

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

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

## tl;dr

7 messages between Oct 13, 2012 and Jan 1, 2013.

replies: 6people: 3as markdown or json

Tomi Belan· Oct 13, 2012, 13:47 UTC · lore

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

Tomi Belan· Oct 21, 2012, 21:18 UTC · re: Tomi Belan · lore

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

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:

Show 35 quoted lines

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

Tomi Belan· Dec 3, 2012, 10:39 UTC · re: Tomi Belan · lore

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

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:

Show 40 quoted lines

> 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

Tomi Belan· Dec 19, 2012, 15:40 UTC · lore

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

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:

Show 51 quoted lines

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

Junio C Hamano· Dec 19, 2012, 15:59 UTC · re: Tomi Belan · lore

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

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.

greened@obbligato.org· Jan 1, 2013, 01:43 UTC · re: Junio C Hamano · lore

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

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

greened@obbligato.org· Jan 1, 2013, 01:40 UTC · re: Tomi Belan · lore

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

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