Re: [1.8.0] Provide proper remote ref namespaces

[Junio C Hamano <gitster@pobox.com>]

Johan Herland <johan@herland.net> writes:

> - Remote tags are now stored separate from local tags. When looking up a 
> shorthand tag name (e.g. v1.7.4), we should consult local tags 
> (refs/tags/v1.7.4) before remote tags (refs/remotes/*/tags/v1.7.4 [1]). See 
> [2] for more details.

> - Remote heads have moved into refs/remotes/$remote/heads/*, hence 
> invalidating shorthand remote head names, like "origin/master". We should 
> change the lookup code, so that a shorthand ref of the form "$remote/$head" 
> where "$remote" happens to match a configured remote is eventually expanded 
> into lookup for "refs/remotes/$remote/heads/$head" [3].

Keeping 'origin/next' usable is a _must_, _if_ we were to go this route.

> - 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).
>
> - All fetch refspecs should be given explicitly.

What do you mean by this?

> Sub-proposal: While we are changing the default refspecs, we should also 
> consider whether we want to keep the auto-following behavior that Git 
> currently does for tags (don't fetch tags that refer to objects not 
> otherwise fetched by another refspec). If we simply make an explicit 
> "+refs/tags/*:refs/remotes/$remote/tags/*" refspec, we will lose the auto-
> following behavior. If we do want to keep the auto-following behavior, we 
> could for example add a "~" prefix to the refspec to trigger auto-following 
> behavior (i.e. this refspec only applies to refs that happen to point at 
> objects fetched by way of a different refspec). See 
> http://thread.gmane.org/gmane.comp.version-control.git/160503/focus=160795 
> for more details.

You seem to envision "auto-follow" to slurp remote tags in remotes/origin/$tag
namespace.  What should "git fetch --tags $from_there" do?

For some reason, many people seem to be enthused about splitting the tag
namespace, but I am not sure if that is a good thing in general.  Branches
are moving pointers for people to flip around in their local repositories,
and it makes sense to say "My master is a bit ahead of the public one",
but what would we gain by making it _easier_ to add and exchange many tags
with the same name (e.g. refs/remotes/*/tags/v1.7.4 vs refs/tags/v1.7.4),
other than the extra confusion?

While you are talking about drastic reorganization (and rewriting the ref
code to support it), another possible Sub-proposal we may want to consider
is to allow "next" and "next/foo" at the same time.