From: Paul Campbell <pcampbell@kemitix.net>
Date: Thu, 07 Mar 2013 15:29:55 GMT
Subject: Re: Questions/investigations on git-subtree and tags
Message-ID: <CALeLG_noUfcOZ8gUjqftz8sfWiWdXP3kZUjkRNJ4W=_J+V70rw@mail.gmail.com>
In-Reply-To: <757358726.204239.1362669338484.JavaMail.root@openwide.fr>

On Thu, Mar 7, 2013 at 3:15 PM, Jeremy Rosen <jeremy.rosen@openwide.fr> wrote:
>> >
>> > Ok, I can understand that you don't want to import tags for
>> > namespace reason, but in that case shouldn't
>> > git subtree add refuse to create a subtree when the tag isn't a
>> > commit
>>
>> It shouldn't and tries not to, but is limited in it's ability to
>> identify if a refspec points to a commit or not in the remote repo.
>>
>
> ok, i've studied a little more
>
> * the target for "git subtree add <url> <refspec> can only be a remote branch or tag, since we git fetch
> can only target remote refs.
> * in case of a branch, git subtree forgets the branch and only use the commit linked to the branch. for
> tags, the fetch part is ok, it's the merge part that fail. adding ^{} at the right place would probably fix that

I think I tried adding the ^{} syntax, but I don't think it works on
remote repos. Or I couldn't get the right syntax.

>>
>> I've posted a patch (which is pending a lot of other changes to
>> git-subtree that I'm corralling) that tries to prevent some obvious
>> errors in the refspec. But letting the git fetch used by git-subtree
>> add and git-subtree pull catch the error and report it may be the
>> best
>> option.
>>
>
> that's interesting... do you have a link ?

Latest patch:

  http://thread.gmane.org/gmane.comp.version-control.git/217257

Prior patch with comments from Junio on what was probably going on
with the old tests:

  http://thread.gmane.org/gmane.comp.version-control.git/217227

>>
>> I've never really tried using --squash, I don't see that it adds any
>> value for me.
>>
>
> my project has a git subtree for a linux kernel and another subtree for buildroot,
>
> a default .git is about 1.5G, squashing it reduces it to 200M so it's worth it for me :)

If disk space is the issue, or bandwidth for initial cloning, then
sure, but I thought Git was efficient enough that a large repo
wouldn't give much of a performance hit.  Unless you use git-subtree
split or push, they are slow.

If git-subtree split could be optimised then --squash wouldn't be
needed as much. It does take an age compared to other Git operations.

-- 
Paul [W] Campbell