From: Marc Branchaud Date: Wed, 02 Feb 2011 19:38:34 GMT Subject: Re: [1.8.0] Remote tag namespace Message-ID: <4D49B2BA.5050002@xiplink.com> In-Reply-To: On 11-02-01 10:35 AM, Nguyen Thai Ngoc Duy wrote: > On Tue, Feb 1, 2011 at 10:07 PM, Marc Branchaud wrote: >>> Config branch.*.globalTags (perhaps takes a pattern?) may be defined >>> to create refs/tags/* in addition to refs/remote-tags//* 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.