[1.8.0] Tag namespaces

On 11-01-31 10:20 PM, Nguyen Thai Ngoc Duy wrote:

On Tue, Feb 1, 2011 at 12:05 AM, Junio C Hamano [off-list ref] wrote:

quoted

Now the 1.7.4 release is out, I'd like people to help thinking about the
next cycle(s).

As a discussion-starter, here are my random wishes.  Even though this does
not attempt to be exhaustive, keeping the number of goals manageably small
may help us focus.

Another random wish, which does not come with a proposal. How about
tag namespace (ie. tags from a remote stay in remote namespace)?

I had just started writing up such a proposal yesterday.  What I have so far
is pretty preliminary:


Proposal:

Change tag refspecs to distinguish between remote and local tags.  An
unadorned tag "foo" could point to different commits in different
repositories.  A remote could move/edit it's "foo" tag and have that update
smoothly propagated to clones.

I believe this was last brought up in November while discussing the refs base
for notes:

http://thread.gmane.org/gmane.comp.version-control.git/160503/focus=160655


Risks:

I think the main risk lies in breaking plain <tagname> refs, as they would
become "origin/<tagname>" refs instead.  But I think that can be mitagated
against (see below).

The other risk folks might raise, though I disagree, is breaking the
immutability assumption for tags.  I'm willing to debate this, though (see
the above-linked thread).

Another "risk" is that this change might be too much of an earthquake.  It
may be something more suitable to a major release, like 2.0.


Migration plan:

Add a "tags.relative" (name TBD) configuration variable which defaults to
false.  When tags.relative is true, "git fetch" puts any received tags under
(location TBD) refs/remotes/<remote>/tags/.  In 1.8.0 we flip tags.realtive's
default value.

To help mitigate the risk of breaking plain "<tagname>" refs, "git rev-parse"
can look for plain names (i.e. ones without a /) in the remote tags location.


		M.