From: Avi Kivity Date: Mon, 22 Feb 2010 18:35:04 GMT Subject: Re: Feature request: separate namespace for remote tags Message-ID: <4B82CE58.8060902@redhat.com> In-Reply-To: <32541b131002221022h57c6bf05mdeb8d27cdbbd1f54@mail.gmail.com> On 02/22/2010 08:22 PM, Avery Pennarun wrote: > On Mon, Feb 22, 2010 at 7:44 AM, Avi Kivity 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.