Re: [1.8.0] Provide proper remote ref namespaces

On Wed, Feb 2, 2011 at 3:21 AM, Johan Herland [off-list ref] wrote:

On Wednesday 02 February 2011, Sverre Rabbelier wrote:

quoted

On Tue, Feb 1, 2011 at 19:14, Jeff King [off-list ref] wrote:

quoted

i.e., make refs/remotes/* an actual mirror of selected parts of the
remote's refs/ hierarchy. And then figure out sane rules for merging
those namespaces into the ref lookup procedure.

Jeff, Nguy, are either of you interested in writing up a new/modifying
this proposal to be about namespacing everything?

Here's my go at phrasing this in a proposal format. Feel free to revise and
resend:

+1

Proposal:

Currently, git stores remote refs in the local repo by default as follows:

 Remote repo    ->   Local repo
 ---------------------------------------------------------
 HEAD                refs/remotes/$remote/HEAD  (implicit)
 refs/heads/*        refs/remotes/$remote/*
 refs/tags/*         refs/tags/*                (implicit, autofollow)
 refs/replace/*      (TBD)
 refs/notes/*        (TBD)

Several users report that they are confused by the difference in how heads
and tags are mapped, and by the implicit mappings that are not mentioned in
the configured refspecs. Also, as users want to share ever more different
types of refs (replace refs and notes refs have been discussed recently),
the existing ref mappings (aka. refspecs) do not suggest a natural/intuitive
mapping for the new ref types.

Instead, we should change the default ref mappings into the following:

 Remote repo    ->   Local repo
 --------------------------------------------------
 HEAD                refs/remotes/$remote/HEAD
 refs/heads/*        refs/remotes/$remote/heads/*
 refs/tags/*         refs/remotes/$remote/tags/*
 refs/replace/*      refs/remotes/$remote/replace/*
 refs/notes/*        refs/remotes/$remote/notes/*

[...]

- We might want to generalize the handling of "$remote/$head" into allowing
shorthands like "$remote/$tag", "$remote/$replace" and "$remote/$note" as
well (provided, of course, that they match unambiguously).

[...]

[2]: When looking up a shorthand tag name (e.g. v1.7.4): If a local tag
(refs/tags/v1.7.4) is found, then we have an unambiguous match. If no local
tag is found, we look up the tag name in all configured remotes (using the
method described in [1]). If the tag name exists in one or more remotes, and
those remotes all agree on its ultimate object name (after applying e.g.
^{commit} or whatever is appropriate in the context of the lookup), then we
also have an unambiguous match. However, if the tag name exists in multiple
remotes, and they do NOT all agree on its ultimate object name, then the
shorthand tag name is ambiguous and the lookup fails. The user can always
resolve this ambiguity by creating a local tag (refs/tags/v1.7.4) pointing
to the desired object.

And the other way around. What would be the output of "git name-rev" ,
"git describe", "--decorate", and such? $remote/tags/$tag?
$remote/$tag? $tag?

I would say $remote/$tag for "git name-rev" and "--decorate" but $tag
for "git describe" as it is usually used to create files, i.e.
git-1.7.4.261.g705f.tar.gz. And I think many people, me included, do
not expect to have an / in the "git describe" output, at least in the
default output (in contrast with the --all flag).

Another point to consider is if we want a default remote for tags, a
config tags.defaultRemote (TBD), defaulting to origin, specifying the
default remote for tags. There would be a hierarchy: local tags,
default remote tags, remote tags. With this if one tag is on multiple
remote the tag from the default remote always wins.

In this way all the tag related input/output would no change much. For
example all the decoration would be $tag instead of origin/tag.

HTH,
Santi