git-subtree.sh - regression introduced by da949cc55

Hello,

Up to this commit, I was able to split out new trees out of sub-directories
of my project.

I used this to create a subproject out of a directory, without necessarily
knowing in advance that I could need the content of this directory in other
projects.

Since da949cc55, older unrelated commits get prepended to the history.

This issue is quite easy to reproduce:

 1. choose a directory in your project which hasn't been added with
    "git subtree add". Let's say it's called my/directory/.
 2. "git subtree split --prefix=my/directory --branch the-new-tree"
 3. "git log --stat the-new-tree"
 4. notice the mess which happens at the first commit concerning
    my/directory/ and how it then includes random older commits which have
    nothing related to my/directory.

Jakub, I'm not sure I understand what this patch is supposed to fix. Could
you provide an example ? Or a test case ?

Thanks !
Marc

On Thu, Feb 11, 2010 at 14:08, Marc Fournier
[off-list ref] wrote:

Jakub, I'm not sure I understand what this patch is supposed to fix. Could
you provide an example ? Or a test case ?

Hi,

there is a test case for the change you're talking about - it's near
the end of test.sh, between "check if split can find proper base
without --onto" and "check_equal ..." (it was added a few commits
later). The problem was that without this commit, in some cases if I
called subtree split for an external project which was earlier added
with git subtree (in order to backport some changes to the original
project) it didn't create the new commits on top of the existing ones
like it should (just look at the test case).

I'll take a closer look at this in the evening...

Jakub Suder

On Thu, Feb 11, 2010 at 8:26 AM, Jakub Suder [off-list ref] wrote:

On Thu, Feb 11, 2010 at 14:08, Marc Fournier
[off-list ref] wrote:

quoted

Jakub, I'm not sure I understand what this patch is supposed to fix. Could
you provide an example ? Or a test case ?

there is a test case for the change you're talking about - it's near
the end of test.sh, between "check if split can find proper base
without --onto" and "check_equal ..." (it was added a few commits
later). The problem was that without this commit, in some cases if I
called subtree split for an external project which was earlier added
with git subtree (in order to backport some changes to the original
project) it didn't create the new commits on top of the existing ones
like it should (just look at the test case).

I'll take a closer look at this in the evening...

Did you have a chance to look at this?

Avery

On Fri, Feb 12, 2010 at 18:52, Avery Pennarun [off-list ref] wrote:

Did you have a chance to look at this?

It's true, when you try to extract a subproject from an ordinary
directory of a project, using git subtree split, it builds the new
branch on top of some past commit, instead of as a completely separate
timeline, and it's exactly because of my change. The problem lies in
what you wrote in the comment above that fragment: "ugly.  is there no
better way to tell if this is a subtree vs. a mainline commit?  Does
it matter?" - well, apparently it does matter :) That line fixed my
problem, because commits in the subproject's timeline should have
cache set to themselves, but it the case when you start from the other
side (first subtree split, not first subtree add), in this fragment
the first commits from the mainline (which are unrelated to the
subdirectory) are regarded as subtree commits, because $tree is empty
(but not because the root directory is different, only because it just
didn't exist yet at this point).

We just need some different way of determining if this is a commit
from subtree timeline or the main timeline - I'll see if I can come up
with something...

JS

On Sat, Feb 13, 2010 at 2:41 PM, Jakub Suder [off-list ref] wrote:

We just need some different way of determining if this is a commit
from subtree timeline or the main timeline - I'll see if I can come up
with something...

Great, thanks.  By the way, the fact that the unit tests didn't catch
this is a bit worrisome, so if you could take a look at that at the
same time it would be great.

(BTW, I just merged a patch from someone to add the long-awaited "git
subtree push" and 2-argument "git subtree add" commands.  So I'm not
*totally* useless. :))

Have fun,

Avery