Re: Local tag killer

From: Michael Haggerty <mhagger@alum.mit.edu>
Date: Sep 29, 2013, 04:29 UTC
Message-ID: <5247ACB9.40208@alum.mit.edu>
In-Reply-To: <CALKQrgeJn1J4ntE_2Lr7Et+Oao=vB1FE6nLfaFJOvLHJLzG9tA@mail.gmail.com>

On 09/28/2013 11:42 PM, Johan Herland wrote:

Show 11 quoted lines

> On Sat, Sep 28, 2013 at 2:20 PM, Michael Haggerty <mhagger@alum.mit.edu> wrote:
>> [...]
>> Nicolas made the two best arguments for the necessity of
>> separate tag namespaces per remote in *some* form:
>> [...]
> 
> I'd also like to mention my initial motivation for the proposal: a
> natural way to organize other types of remote refs (notes, replace
> refs, etc.). The separate tag namespace came about as a natural
> (and IMHO quite useful) consequence of the proposed reorganization
> of refs/remotes/*.

ACK.

Show 24 quoted lines

>> Other discussion and open issues regarding a ref namespace reorg:
>>
>> * What exactly would be the ambiguity rules for references with the same
>>   name that appear in multiple remotes' namespaces?
>>
>>   * Are references to two annotated tags considered the same if they
>>     refer to the same SHA-1, even if the annotated tags are different?
>>     What about an annotated vs an unannotated tag?  The consensus
>>     seemed to be "no".
>>
>>   * Do they depend on how the reference is being used?  Yes, sometimes
>>     only a SHA-1 is needed, in which case multiple agreeing references
>>     shouldn't be a problem.  Other times the DWIM caller needs the
>>     full refname (e.g., "git push" pushes to different locations
>>     depending on whether the source is a branch or tag), in which case
>>     the rules would have to be more nuanced.
> 
> Could we try to classify all ref lookups as either ref _name_ lookups
> (in which case only a single, matching full refname is acceptable), or
> ref _value_ lookups (in which case multiple matching names are allowed,
> as long as they all point to the same SHA-1)? There are some complicated
> cases (e.g. describe) which needs more thought, but if we can agree on
> a mechanism for dealing with all the simpler cases, that might help
> inform how to deal with the complicated ones.

Yes, name vs. value lookups is a useful distinction.

Show 10 quoted lines

> [...]
>> * 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/*'

Show 15 quoted lines

>> [...]
>> * 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.
>>   [Would it work to configure the fetching repo something like
>>
>>   [remote "gitk-origin"]
>>           fetch = refs/tags/*:refs/remotes/gitk-origin/tags/gitk/*
>>
>>   and to refer to a hypothetical gitk tag "v1.2.3" as "gitk/1.2.3"?
>>   Admittedly this is somewhat ambiguous with the proposed DWIM pattern
>>   <REMOTE>/<TAGNAME>.]
> 
> Only if you also had a remote called "gitk". ;)

True.

Show 12 quoted lines

> An alternative way to solve the problem of many ambiguity warnings:
> If we define the rules so that local tags always override remote tags,
> you could simply fetch the tags from your preferred remote into your
> local tag namespace (as discussed above).
> 
> Personally, I would rather set up the configuration like this:
> 
>   [remote "gitk"]
>           fetch = refs/tags/*:refs/remotes/gitk/tags/*
> 
> (i.e. keeping the default refspec) and then use "gitk/v1.2.3",
> "git/v.1.2.3", "gitgui/v1.2.3" to disambiguate between the tags.

But if there were more than one remote providing gitk tags, it would be difficult to grab a tag without caring where it came from. And where would I create a local gitk-scope tag?

I wonder whether remotes.group could sensibly be used to group remotes into logical groups for value lookups:

    [remotes]
            gitk = gitk-origin
            gitk = second-gitk-repo

Then DWIM could be taught to seek "gitk/foo" under "refs/remotes/gitk-origin/tags/foo" and "refs/remotes/second-gitk-repo/tags/foo" in addition to "refs/tags/gitk/foo" (insisting, of course, that if more than one of these are present that they are all consistent).

Remote groups might also be used to configure the remotes that describe considers when describing a commit:

    [remotes]
            describe = junio
            describe = jrn

or maybe (using the above config)

    git describe --remote-group=gitk

Show 5 quoted lines

>> [...]
>> @Johan, I know that you were working on the ref-namespace issue at
>> GitMerge.  Did your work get anywhere? Are you still working on it?
> 
> I posted [...]

Thanks for your comments, and for the status update!

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/