Re: [1.8.0] Remote tag namespace

[Marc Branchaud <marcnarc@xiplink.com>]

On 11-02-01 10:35 AM, Nguyen Thai Ngoc Duy wrote:
> On Tue, Feb 1, 2011 at 10:07 PM, Marc Branchaud<marcnarc@xiplink.com>  wrote:
>>> 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.

IMHO, it's best not to assume what people might want.  Better to wait 
for someone to ask for something specific.

[ ...snip... ]

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

I think we could start by making "git tag -A" a synonym for "git tag -a" 
with a verbose warning when "-a" is used that it'll soon gain a 
different meaning.

Also, during the transition "git tag -a" without any other options could 
(without the big warning) list all local and remote tags (like "git 
branch -a") and if someone wanted to make an annotated tag of the 
current tip they could do "git tag -A" or "git tag -a HEAD".

		M.