Re: 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 <marc.fournier@camptocamp.com> wrote:

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 <jakub.suder@gmail.com> wrote:

Did you have a chance to look at this?

Avery

On Fri, Feb 12, 2010 at 18:52, Avery Pennarun <apenwarr@gmail.com> wrote:

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 <jakub.suder@gmail.com> wrote:

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