Re: Local tag killer

[Nicolas Pitre <nico@fluxnic.net>]

On Mon, 30 Sep 2013, Marc Branchaud wrote:

> On 13-09-30 11:52 AM, Nicolas Pitre wrote:
> > Consider that I have in my Linux kernel tree:
> > 
> > - a remote branch corresponding to Linus' master tree
> > 
> > - multiple remote branches corresponding to Linux stable branches
> > 
> > - a remote for linux-next which is a repo constantly being rebased
> > 
> > Now all those repositories share the mainline tags from Linus' repo and 
> > they add some more of they own which are not shared.  So if they all 
> > have a v3.11 tag that resolve to the same SHA1, then there is 
> > effectively no ambiguity at all and git should not warn at all.
> 
> Thanks, this example helps very much.
> 
> > *However* if one of those v3.11 tags does not agree with the others 
> > _then_ I want to be warned about it.
> 
> Hmmm.  What behaviour would you like if you also had some non-Linux remote,
> say for some driver code or something, that also had a v3.11 tag?

I want git to complain and bail out, maybe suggesting that I should use 
"driver_something/tag/v3.11" to disambiguate the tag.

> I presume
> you want commands like
> 	git checkout -b my-topic v3.11
> to do the Right Thing, but what's the right thing for you here?

git itself can't know it.  So the best git could do is to list 
conflicting tags with the shortest path that makes them unambiguous and 
suggest that I try again with one of them.

> > So having multiple matching tags that do resolve to the same SHA1 across 
> > different remote repositories _is_ the norm and should work 
> > transparently.
> 
> My suggestion for your example is that if some remote's tags are so
> important/useful then you're better off importing them into your local tag
> namespace (e.g. "git fetch Linus refs/tags/*:refs/tags/*").  By making the
> remote's tags local, you're expressly telling git that they should be
> considered for DWIMery, git-describe, etc.

Sure, it is probably a good thing semantically to give priority to local 
tags when they exist. However...

> I feel this approach lets us avoid having to somehow teach git which remote's
> "v3.11" tags are important enough to merit an ambiguity warning and which
> aren't.  Plus you get what I think you want, which is the current behaviour.

But I disagree here.  Most people simply won't care about local tags 
since the remote tags are sufficient for what they need.  And if they 
have multiple remotes in their repository then it is most likely to be 
different forks of the same project sharing mostly the same tags, and 
where those tags diverge then they're most likely to have different tag 
names as well.  So in the large majority of the cases, this v3.11 tag 
will come from one or more remotes and they will refer to the same SHA1, 
so it ought to just work without any special fetch.  Also, if I refer to 
v3.11.1 which is a tag that only exists in one of the remote branches 
and not in Linus' remote then it ought to just work as well.  That is 
more inline with the current _usage_ behavior even if the flat namespace 
is otherwise a nightmare to sort out when managing remotes.

Furthermore, git already has some code to detect refname ambiguities:

$ git init && echo "foo" > foo.txt && git add foo.txt
$ git commit -m "foo" && git tag foo && git branch foo && git log foo
warning: refname 'foo' is ambiguous.

So adding the extra step to lookup all possible tags and make sure they 
resolve to the same SHA1 should be a logical extension to what's already 
there.

Again, in the cases where there is actually a SHA1 conflict between all 
possible tags that match a tag short-end then listing them and asking the 
user to be more explicit is the right thing to do.  But that should be a 
very rare case in practice, and designing for making this case easy is 
the wrong approach.

Instead, the common case of multiple remotes with duplicated tag names 
referring to the same thing _and/or_ multiple remotes with distinct tags 
names is what should be made easy to use with no extra steps.


Nicolas