Re: [1.8.0] Provide proper remote ref namespaces

From: Jeff King <peff@peff.net>
Date: Feb 7, 2011, 20:19 UTC
Message-ID: <20110207201912.GB13461@sigill.intra.peff.net>
In-Reply-To: <201102070958.11551.johan@herland.net>

On Mon, Feb 07, 2011 at 09:58:11AM +0100, Johan Herland wrote:

Show 8 quoted lines

> > No, that won't give you me/shawn/junio/v1.7.4, but it does mean we have
> > to gracefully handle the case of ambiguous duplicate tags (that happen
> > to point to the same thing).
> 
> Whoa, we use the "ambiguous" term differently here. In this whole thread I 
> have used "ambiguous" exclusively about when the same (shorthand) tag name 
> point to _different_ things. As long as they point to the same thing, there 
> is no ambiguity, IMHO.

Sorry, I should have been more clear. I meant "ambiguous by the current code's definition", meaning "we would still need to use your new ambiguity definition to resolve this situation".

IOW, I think we are on the same page.

Show 7 quoted lines

> This is the same technique we use when talking about branch names: On this 
> mailing list, nobody is confused when I refer to 'maint', 'master', 'next' 
> and 'pu'. Still, in our own work repos (at least in mine), these branches 
> are actually called "refs/remotes/origin/<name>" (commonly referred to by 
> their shorthands "origin/<name>"). Here we are, juggling the same kind of 
> namespaces that I propose for tags, and it seems to work well without 
> causing much confusion.

Just playing devil's advocate for a moment: isn't this namespace distinction one of the more confusing things in git for new users? That is, I have seen new-ish git users say "OK, so I cloned from upstream. How come I can't say "git log maint" now?" Or it used to be "how come I can't "git checkout maint" now?" The latter is now handled by some very specific magic in "git checkout", but in general ref lookup does not automagically look in remotes namespaces, and it has caused some confusion.

So here we are introducing more distinction between project-wide names and per-remote names. I absolutely think it's the right thing to do from a "keep it simple, orthogonal, and distributed" perspective. But we also need to recognize we are making some common use cases more confusing. In the case of remote-tracking branches, we ended up adding some porcelain features to make common actions (like checking out a local branch from a remote) more seamless. But there is still some confusion among new users.

I'm sort of rambling as I'm not quite sure yet what this means for the tags proposal, but a few questions I think are important to consider are:

  1. Where have we succeeded and where have we failed with making
     separate-remotes / tracking branches seamless to the user (as
     opposed to something like a system where
     fetching from upstream fetches straight into your master branch
     (which has its own problems, but would be conceptually very
     simple)? Do those failures apply in this case, and if so how can we
     do better?

  2. Can we apply new ideas for handling separate-remote tags to the
     branches case? Obviously one big proposal is searching in the
     per-remote tag namespace for refs. Should we be doing the same with
     heads?

-Peff