Re: [1.8.0] Remote tag namespace

From: Nguyen Thai Ngoc Duy <pclouds@gmail.com>
Date: Feb 1, 2011, 15:35 UTC
Message-ID: <AANLkTim4qOiF=3GMixZuWJs=cqcAtawtgkKzLiVdBhuZ@mail.gmail.com>
In-Reply-To: <4D48219D.8060603@xiplink.com>

On Tue, Feb 1, 2011 at 10:07 PM, Marc Branchaud <marcnarc@xiplink.com> wrote:

Show 8 quoted lines

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

Ahh.. yeah it's remote.*.globalTags. I don't know, some people might find current behavior useful. So instead of dropping it entirely, I'd limit it to certain remotes.

Show 11 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.

For listing tags (I forgot this) I think we just follow how git-branch does it: show only local tags unless -r (or some other option) is given. What I meant in the above paragraph is "some-ref" can refer to refs/tags/some-ref or refs/remotes/foo/tags/some-ref, but I was wrong on this. The latter can only be referred by foo/some-ref or with migration support in your proposal.

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

When tags are put in remote namespace (wherever it actually is), git-tag must learn -r like git-branch. I think option name change for -a is too late though. When "git-ng" rewrite project comes (that is after libgit2 replaces git core), we may have everything consistent again.

PS. I bet git-ng would start after Wine 2.0 is released.

-- 
Duy