Re: Local tag killer

[Marc Branchaud <mbranchaud@xiplink.com>]

On 13-09-29 12:29 AM, Michael Haggerty wrote:
> On 09/28/2013 11:42 PM, Johan Herland wrote:
>> On Sat, Sep 28, 2013 at 2:20 PM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
>> [...]
>>> * How would somebody (e.g., an interim maintainer) suck down tags from
>>>   a project into his own refs/tags/* namespace?  (Would it even be
>>>   necessary?)
>>
>> I'm not convinced it would be necessary. I have yet to see a case where
>> a (suitably unambiguous) remote tag would not fulfill the same purpose
>> as the equivalent local tag. The only exception is for dealing with
>> ambiguous remote tags, where a local tag could be created to serve as a
>> tie-breaker.
> 
> I guess I was wondering how the interim maintainer would get Junio's
> tags into his public repo (which he would want to do, so that users can
> get everything from a single clone).
> 
> I think that the new version of "git push --tags" should *not* push all
> tags from all remotes; it should push only refs/tags, like now.  So I
> was thinking that the interim maintainer would want to import Junio's
> tags into his own namespace, then
> 
>     git push --tags $URL
> 
> But I guess it would be cleaner just to push using an explicit refspec:
> 
>     git push $URL 'refs/remotes/origin/tags/*:refs/tags/*'

(Thanks for the awesome summary!)

You seem to be considering the case of an interim maintainer who, prior to
becoming the maintainer, has his own clone of the "official" repo and now
wants to make his clone the "official" repo, perhaps only temporarily.

But what if the interim maintainer has his own tags in his clone?  What if,
after he is no longer the interim maintainer, he wants to remove the
"official" tags from his clone's local namespace?  The interim maintainer
might also have his own branches in his clone, which shouldn't be part of an
"official" repo.

It seems to me that an interim maintainer would be wise to simply mirror the
"official" repo and publish with that mirror.  So the gymnastics you're
contemplating don't seem necessary to me.

>>> [...]
>>> * How would this help somebody who wants to fetch content from multiple
>>>   projects (e.g., git, gitk, gitgui) into a single repo?  There might
>>>   be tags with the same names but very different meanings, and it would
>>>   be awkward if there were ambiguity warnings all over the place.

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

And as for git-describe, I think it should only consider remote namespaces
when asked to via a command-line option or configuration setting (again
following the behaviour of git-branch).  Let whoever implements such an
option define whatever disambiguation rules they like.  Although I'd suggest
that the first implementation be very simple so that we can learn how people
expect it to work.  We may just find that users don't want git-describe to
consider remote namespaces at all.

Aside from that, I guess I just don't see a problem with using the existing
branch name disambiguation rules.  Am I missing something?

		M.