Re: Local tag killer

From: Marc Branchaud <marcnarc@xiplink.com>
Date: Sep 30, 2013, 19:16 UTC
Message-ID: <5249CDF7.4050904@xiplink.com>
In-Reply-To: <alpine.LFD.2.03.1309301138200.6331@syhkavp.arg>

On 13-09-30 11:52 AM, Nicolas Pitre wrote:

Show 27 quoted lines

> On Mon, 30 Sep 2013, Marc Branchaud wrote:
> 
>> Why would there be ambiguity warnings?  The fetch command shouldn't issue any
>> warnings, since all the remotes' names get safely tucked away in distinct
>> namespaces.
>>
>> Are we talking about DWIM warnings?  Aside from git-describe I don't see why
>> such warnings would be a problem.  To DWIM-resolve a tag name look in
>> refs/tags/* and refs/remotes/*/tags/* -- much like it's done for branches
>> already.  If a tag name has multiple matches then it's ambiguous.  Git could
>> be clever and check for matching SHA1 values, but why bother?  It almost
>> seems like a disservice to silently disambiguate such names.  I would think a
>> user would prefer to know about any possible ambiguities, rather than have
>> some suddenly appear (and maybe also disappear).
> 
> 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 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?

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

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.

If this works for you, maybe it gives us a way forward: All the DWIM machinery should only consider the local namespace, perhaps with options to explicitly ask it to expand its search, and we leave it up to the user to specify which remotes' namespaces should be imported into the local namespace?

M.