On 09/28/2013 11:42 PM, Johan Herland wrote:
> On Sat, Sep 28, 2013 at 2:20 PM, Michael Haggerty <mhagger@xxxxxxxxxxxx> 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.
>> 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.
> [...]
>> * 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/*'
>> [...]
>> * 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.
> 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
>> [...]
>> @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@xxxxxxxxxxxx
http://softwareswirl.blogspot.com/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html