Re: Questions/investigations on git-subtree and tags

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Mar 7, 2013 at 3:15 PM, Jeremy Rosen <jeremy.rosen@xxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]