[1.8.0] Tag namespaces

[Marc Branchaud <marcnarc@xiplink.com>]

On 11-01-31 10:20 PM, Nguyen Thai Ngoc Duy wrote:
> On Tue, Feb 1, 2011 at 12:05 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> 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.