Re: [1.8.0] Provide proper remote ref namespaces

[Johan Herland <johan@herland.net>]

On Monday 07 February 2011, Jeff King wrote:
> On Mon, Feb 07, 2011 at 09:58:11AM +0100, Johan Herland wrote:
> > 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?

I pretty much completely agree with your train of thought.

First, although the separate-remotes may at first be confusing to newbies 
coming from a centralized VCS, I don't think this is the _main_ source of 
confusion. And, as you imply, we cannot eliminate this kind of conceptual 
confusion in any case, without violating core DVCS principles (like Bazaar 
does in its "centralized workflow"). The best way to address this is, as you 
say, by keeping it "simple, orthogonal, and distributed" (and try very hard 
to keep the common use cases minimally affected).

We should instead look at what other (and preferrable fixable) sources of 
confusion we have in this area. Answering Git questions from colleagues at 
$dayjob, they often describe how they tried to accomplish something in Git, 
and I sometimes find myself giving a reply of the following form: "Yes, what 
you tried does make sense from your POV, but in this situation Git actually 
does this other thing instead, so instead you have to do ...". I don't like 
giving answers like this, because I get this nagging feeling that the 
problem is Git's fault, and not the user's. So, to enumerate some of these 
inconsistencies (I'm sure there are more that I cannot recall, right now):

- Lack of consistency in the ref namespace (refs/remotes/$remote/* vs. 
refs/tags/*). Also not clear from the current layout where to add new types 
of refs (e.g. notes, replace). My proposal tries to address this issue.

- Lack of consistency in which fetch refspecs must be listed in the 
configuration. (i.e. implicit vs. explicit fetch refspecs). My proposal 
tries to address this as well.

- Lack of consistency in porcelain interfaces. Some of these have been fixed 
in recent Git version, but some are yet to be fixed: E.g. some find the use 
of FETCH_HEAD confusing (when does fetch update the remote refs, and when 
does it update FETCH_HEAD instead?). Others (myself included) wonder why 
'git push' by default updates remote branches with matching names, while 
'git pull' relies on the explicitly configured upstreams to update the local 
refs. (FWIW, I've mitigated this last complaint insisting that all users at 
$dayjob run "git config --global push.default tracking" immediately after 
installing Git.) There are other UI inconsistencies too that escape me ATM.

When it comes to your second question, I believe it's definitely worth 
looking closer at whether we can exploit unambiguity across namespaces for 
all types of refs (not just tags). I expect there are some non-trivial 
issues down that road (some of these being discussed elsewhere in this 
thread), but we may still end up with something better.


Thanks for the feedback! :)

...Johan

-- 
Johan Herland, <johan@herland.net>
www.herland.net