Re: Local tag killer

[Marc Branchaud <marcnarc@xiplink.com>]

On 13-09-30 04:08 PM, Nicolas Pitre wrote:
> 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.

Good point -- I see where my suggestion was wrong.  I think it's worthwhile
to make sure that bare tag names "just work" after a simple clone.  Git's
DWIM code already does this for branch names, and it makes sense to extend
that to other ref types in remote namespaces.

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

I disagree about the "most likely" part, but it's only a niggle.  I agree
with the overall point that disambiguation through SHA1 comparison makes sense.

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

Agreed.

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

Again, I don't think that's the common case.  I think it's just as likely for
there to be multiple remotes with duplicate tag names that refer to different
objects.  However, SHA1-disambiguation covers all these cases.

		M.