Re: [1.8.0] Remote tag namespace

From: Marc Branchaud <marcnarc@xiplink.com>
Date: Feb 1, 2011, 15:07 UTC
Message-ID: <4D48219D.8060603@xiplink.com>
In-Reply-To: <AANLkTi=yFwOAQMHhvLsB1_xmYOE9HHP2YB4H4TQzwwc8@mail.gmail.com>

On 11-02-01 05:44 AM, Nguyen Thai Ngoc Duy wrote:

Show 9 quoted lines

> On Tue, Feb 1, 2011 at 11:16 AM, Nicolas Pitre <nico@fluxnic.net> wrote:
>> On Tue, 1 Feb 2011, Nguyen Thai Ngoc Duy wrote:
>>> Another random wish, which does not come with a proposal. How about
>>> tag namespace (ie. tags from a remote stay in remote namespace)?
>>
>> Please make this into a proper proposal.  this would be indeed a huge
>> improvement.
> 
> OK I'm not familiar with tag code, but I can try.

OK, that teaches me to read through _all_ the unread messages before posting!

Needless to say, I support this proposal.

Show 7 quoted lines

> Proposal:
> 
> Reserve refs/remote-tags namespace to store tags from remotes. Its
> structure is the same as in refs/remotes. When pulling tags, put them
> in refs/remote-tags/<remote> instead of refs/tags.
> Tag dereference code will be taught about refs/remote-tags with
> similar deref order as in remote branches.

I suggested a different home for the tags, but I don't have any insight into what makes the most sense. I'll defer to wiser folk on this.

> Config branch.*.globalTags (perhaps takes a pattern?) may be defined
> to create refs/tags/* in addition to refs/remote-tags/<remote>/* when
> fetching tags.

I may be getting into the weeds prematurely here, but why put the config item under branch.* ? Or did you mean remote.*.globalTags? Personally, I don't see a need for this. I'd rather have the rev-parse machinery search in remote tag namespaces if it can't find anything local.

Show 6 quoted lines

> Migration plan:
> 
> refs/remote-tags will be used to store new tags unconditionally, which
> means there will be duplicates with the already-fetched tags in global
> namespace. Perhaps we can check if they point to the same sha-1, then
> choose not to annoy users with ambiguous tag messages?

(Again with the weeds...) I don't think we could do that. I'd want to be able to have my own (local) tags that refer to the same commits as one or more remote tags, and I'd want to see them all.

Better for "git tag" to learn scoping options like "git branch": -a and -r. (Hmm, maybe git-tag's current -a could become -A...)

Show 10 quoted lines

> I suggest to add config compatibility.remoteTagNamespace, default to
> false, which retains current behavior (i.e. also create tags in global
> namespace in addition to refs/remote-tags). After 1.8.0 (or a few more
> cycles) the default value becomes true. Users who wish to keep old
> behavior can put "false" in their ~/.gitconfig.
> 
> After a few years, remove support for the config key. Unrecognized
> compatibility.* keys will abort program. Users are forced to new
> behavior. I don't know, we may want to start annoy users that have the
> config key set a few cycles before we drop support.

Sounds good.  I'd vote for a faster transition, but that's just me.  :)

M.