{"thread":{"id":"22756","subject":"Feature request: separate namespace for remote tags","startedAt":"2010-02-22T12:44:56Z","lastAt":"2010-02-22T18:35:04Z","messageCount":3,"participants":["Avi Kivity","Avery Pennarun"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"135309","messageId":"4B827C48.9060601@redhat.com","threadId":"22756","inReplyTo":null,"subject":"Feature request: separate namespace for remote tags","fromName":"Avi Kivity","fromEmail":"avi@redhat.com","sentAt":"2010-02-22T12:44:56Z","receivedAt":"2010-02-22T12:44:56Z","isPatch":false,"sender":{"key":"avi@redhat.com","avatar":null},"body":"Currently, 'git remote add foo ...' will allocate a separate namespace \nfor foo branches (refs/remotes/foo/*) but will store foo tags in the \nmain tag namespace (refs/tags/*).  This leads to several problems:\n\n- the main tag namespace becomes polluted with zillions of tags\n- if the tags from a remote conflict with a local (or perhaps another \nremote) tag, information is lost\n- 'git remote rm' will not delete the remote tags, and so 'git gc' will \nnot recover much of the space used by the remote\n\nA workaround is to use tagopt = --no-tags and a separate fetch line in \nthe remote configuration, but that is clumsy and error prone (a common \nerror being to remember doing that only after the first fetch).  I'd \nlike to request that remote tags be placed into a separate namespace \n(refs/remote-tags/foo/*?) that can be managed by 'git remote' subcommands.\n\nMy suggestion is:\n\n- 'git clone' and subsequent fetches would continue to place tags in the \nglobal namespace (unless overridden by a switch)\n- 'git remote add', if a switch of config flag is present, will place \ntags in a remote namespace; after a while the config flag can default to \ntrue\n- 'git describe' will prefer local tags to remote tags\n- the various commands which look at tags will be enhanced to consider \nremote tag namespaces\n- possibly ignore remote tags which have the same name and value as \nexisting local tags (so we don't have identical v1.7.0 and foo/v1.7.0)\n\nThoughts?\n\n-- \nerror compiling committee.c: too many arguments to function\n"},{"id":"135333","messageId":"32541b131002221022h57c6bf05mdeb8d27cdbbd1f54@mail.gmail.com","threadId":"22756","inReplyTo":"4B827C48.9060601@redhat.com","subject":"Re: Feature request: separate namespace for remote tags","fromName":"Avery Pennarun","fromEmail":"apenwarr@gmail.com","sentAt":"2010-02-22T18:22:57Z","receivedAt":"2010-02-22T18:22:57Z","isPatch":false,"sender":{"key":"apenwarr@gmail.com","avatar":"https://avatars.githubusercontent.com/u/20592?v=4"},"body":"On Mon, Feb 22, 2010 at 7:44 AM, Avi Kivity <avi@redhat.com> wrote:\n> Currently, 'git remote add foo ...' will allocate a separate namespace for\n> foo branches (refs/remotes/foo/*) but will store foo tags in the main tag\n> namespace (refs/tags/*).  This leads to several problems:\n>\n> - the main tag namespace becomes polluted with zillions of tags\n> - if the tags from a remote conflict with a local (or perhaps another\n> remote) tag, information is lost\n> - 'git remote rm' will not delete the remote tags, and so 'git gc' will not\n> recover much of the space used by the remote\n\nI've sometimes wished for such a feature myself.  When merging things\nusing git-subtree, for example, you can easily end up importing\n\"v1.2.3\" type tags from two different projects and causing yourself\ntotal confusion.\n\nHowever, just dividing the tags into namespaces removes one of the\nnicest features of tags, which is that they uniquely identify a\nparticular revision across all repositories.  The whole point is that\nap/v1.2.3 isn't ever supposed to differ from origin/v1.2.3.\n\nOne option would be to split the tags into namespaces, but then\nautomatically search all namespaces when looking for a particular tag.\n Then when you drop a particular remote, you'd lose all its tags, but\nif you *don't* drop that remote, things look like they always have.\n\nHave fun,\n\nAvery\n"},{"id":"135335","messageId":"4B82CE58.8060902@redhat.com","threadId":"22756","inReplyTo":"32541b131002221022h57c6bf05mdeb8d27cdbbd1f54@mail.gmail.com","subject":"Re: Feature request: separate namespace for remote tags","fromName":"Avi Kivity","fromEmail":"avi@redhat.com","sentAt":"2010-02-22T18:35:04Z","receivedAt":"2010-02-22T18:35:04Z","isPatch":false,"sender":{"key":"avi@redhat.com","avatar":null},"body":"On 02/22/2010 08:22 PM, Avery Pennarun wrote:\n> On Mon, Feb 22, 2010 at 7:44 AM, Avi Kivity<avi@redhat.com>  wrote:\n>    \n>> Currently, 'git remote add foo ...' will allocate a separate namespace for\n>> foo branches (refs/remotes/foo/*) but will store foo tags in the main tag\n>> namespace (refs/tags/*).  This leads to several problems:\n>>\n>> - the main tag namespace becomes polluted with zillions of tags\n>> - if the tags from a remote conflict with a local (or perhaps another\n>> remote) tag, information is lost\n>> - 'git remote rm' will not delete the remote tags, and so 'git gc' will not\n>> recover much of the space used by the remote\n>>      \n> I've sometimes wished for such a feature myself.  When merging things\n> using git-subtree, for example, you can easily end up importing\n> \"v1.2.3\" type tags from two different projects and causing yourself\n> total confusion.\n>\n> However, just dividing the tags into namespaces removes one of the\n> nicest features of tags, which is that they uniquely identify a\n> particular revision across all repositories.  The whole point is that\n> ap/v1.2.3 isn't ever supposed to differ from origin/v1.2.3.\n>    \n\nThat's why I suggested not creating ap/v1.2.3 if it matches \nrefs/tags/v1.2.3 (a clone would default to using regs/tags, not \nrefs/remote-tags/origin).  If they don't match, at least you don't lost \ninformation.\n\n> One option would be to split the tags into namespaces, but then\n> automatically search all namespaces when looking for a particular tag.\n>   Then when you drop a particular remote, you'd lose all its tags, but\n> if you *don't* drop that remote, things look like they always have.\n>    \n\nYes.\n\n-- \nDo not meddle in the internals of kernels, for they are subtle and quick to panic.\n"}]}