Re: Feature request: separate namespace for remote tags

[Avi Kivity <avi@redhat.com>]

On 02/22/2010 08:22 PM, Avery Pennarun wrote:
> On Mon, Feb 22, 2010 at 7:44 AM, Avi Kivity<avi@redhat.com>  wrote:
>    
>> Currently, 'git remote add foo ...' will allocate a separate namespace for
>> foo branches (refs/remotes/foo/*) but will store foo tags in the main tag
>> namespace (refs/tags/*).  This leads to several problems:
>>
>> - the main tag namespace becomes polluted with zillions of tags
>> - if the tags from a remote conflict with a local (or perhaps another
>> remote) tag, information is lost
>> - 'git remote rm' will not delete the remote tags, and so 'git gc' will not
>> recover much of the space used by the remote
>>      
> I've sometimes wished for such a feature myself.  When merging things
> using git-subtree, for example, you can easily end up importing
> "v1.2.3" type tags from two different projects and causing yourself
> total confusion.
>
> However, just dividing the tags into namespaces removes one of the
> nicest features of tags, which is that they uniquely identify a
> particular revision across all repositories.  The whole point is that
> ap/v1.2.3 isn't ever supposed to differ from origin/v1.2.3.
>    

That's why I suggested not creating ap/v1.2.3 if it matches 
refs/tags/v1.2.3 (a clone would default to using regs/tags, not 
refs/remote-tags/origin).  If they don't match, at least you don't lost 
information.

> One option would be to split the tags into namespaces, but then
> automatically search all namespaces when looking for a particular tag.
>   Then when you drop a particular remote, you'd lose all its tags, but
> if you *don't* drop that remote, things look like they always have.
>    

Yes.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.