Re: Why aren't tag refs namespaced?

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 27, 2012, 03:26 UTC
Message-ID: <xmqq62cl7t40.fsf@junio.mtv.corp.google.com>
In-Reply-To: <CA+7g9JzpLkNHT_o1QyJ_r=4DrauWOPFr5XR_CPeAHGcLpLoD+w@mail.gmail.com>

Nathan Gray <n8gray@n8gray.org> writes:

Show 5 quoted lines

>> Other workflows that use private tags are possible and they might
>> benefit from having separate namespaces; it is just that they are not
>> the workflow Git was originally designed to support.
>
> That makes sense.

Yeah, as I said, the current behaviour aims to support a particular workflow, e.g.

 * "git fetch --tags" uses a built-in refspec "refs/tags/*:refs/tags/*"
   and that maps a tag at the remote to the same location in the refs/
   hierarchy in the local repository.

 * "git fetch" that stores the history it fetches to local repository
   (i.e. uses refspec with non-empty RHS), when run without "--no-tags",
   fetches tags that point at commits in the fetched history from the
   remote and stores them at the same location in the refs/ hierarchy.

and does it well.

But there is nothing in Git that fundamentally forces you to follow that pattern. It is entirely plausible to enhance the former (i.e. --tags) to a bool-or-string option to let you specify different refs/ hierarchy (e.g. "--tags" would use "refs/tags/*:refs/tags/*" to map the names, while "--tags=refs/remotes/origin/tags" might store fetched tags in specified place that is different from refs/tags/), and to add a new option to specify where the auto-followed tags would be stored to enhance the latter.