Re: [1.8.0] Tag namespaces

On Tue, Feb 1, 2011 at 9:54 PM, Marc Branchaud [off-list ref] wrote:

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

quoted

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:

Thanks. I wrote another proposal (should we have more or less standard
"Git Enhancement Proposal" process like Python's PEP or Scheme's SRFI
to keep track of these over time?) but it's good to see others look at
it too.

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

One problem with the proposed ref layout is that it breaks current
layout (remotes/<remote>/head -> remotes/<remote>/heads/head). Some
sort of migration support is needed. On the other hand, new layout is
cleaner than my proposal (remote-tags/<remote>/tag).

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).
...
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.

Hmm I thought "a-ref" would check "refs/tags/a-ref" and
"refs/remotes/*/a-ref". But you are right. Maybe "tags.relative" can
take three values instead of boolean (names TBD):

 - deprecated (current behavior)
 - migrating (fetch tags to refs/remotes, but tag lookup will look in
refs/tags as well as refs/remotes/*/tags)
 - migrated (fetch tags to refs/remotes, look up in order)

We may slowly turn default value step by step until it becomes "migrated".
-- 
Duy