Thread (18 messages) flat view 18 messages, 7 authors, 2016-06-15

Re: [1.8.0] Remote tag namespace

From: Marc Branchaud <hidden>
Date: 2016-06-15 22:50:29

On 11-02-01 10:35 AM, Nguyen Thai Ngoc Duy wrote:
On Tue, Feb 1, 2011 at 10:07 PM, Marc Branchaud[off-list ref]  wrote:
quoted
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help