Re: [1.8.0] Provide proper remote ref namespaces
- From
- Santi Béjar <santi@agolina.net>
- Date
- Feb 2, 2011, 13:27 UTC
- Message-ID
- <AANLkTimqQtLB--7pwwTALmcchnNCX0nm4Rfx8w1gp74T@mail.gmail.com>
- In-Reply-To
- <201102020322.00171.johan@herland.net>
On Wed, Feb 2, 2011 at 3:21 AM, Johan Herland <johan@herland.net> wrote:
Show 12 quoted lines
> On Wednesday 02 February 2011, Sverre Rabbelier wrote: >> On Tue, Feb 1, 2011 at 19:14, Jeff King <peff@peff.net> wrote: >> > 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
Show 29 quoted lines
> > 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).
[...]
Show 11 quoted lines
> [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