Re: [1.8.0] Provide proper remote ref namespaces

From: Jakub Narebski <jnareb@gmail.com>
Date: Feb 11, 2011, 15:13 UTC
Message-ID: <m3mxm28v3i.fsf@localhost.localdomain>
In-Reply-To: <201102080159.02153.johan@herland.net>

Johan Herland <johan@herland.net> writes:

> On Monday 07 February 2011, Jeff King wrote:
> > On Mon, Feb 07, 2011 at 09:58:11AM +0100, Johan Herland wrote:

Show 12 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 "where are all the branches?" ('git branch' doesn't show remote-tracking branches).

> > 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.

One has to be very careful with DWIM-mery, lest it would increase confusion instead of reducing it.

[...]

Show 7 quoted lines

> 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).

Well, I think the confusion was greater and more dangerous in pre-separate remotes era ('master' mapped to 'origin', branches mapped to themselves, for single 'origin' remote).

> - 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.

The lack of consistency is there because tags should USUALLY be global
(there should be only one v1.7.4), while branch names should be local
(my 'master' branch is not your 'master' branch).
 
In some cases, like joining or subtree-merging unrelated projects we
would want local / per-remote tags: 'v1.7.4' in main project is not
'v1.7.4' in 'foo' subproject (in 'foo' remote).  Currently we lack a
way to specify that (the 'autofollow' refspec proposal, default
behaviour would be equivalent to '~refs/tags/*:refs/tags/*"), and lack
support from porcelain: MY PROPOSAL is to add '--use-separate-tags'
(like old '--use-separate-remote') to "git clone" and "git remote add",
and perhaps '--alternate' as equivalent to '--no-separate-tags' to 
"git remote add".

> - 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.

Could you repeat your proposal? Do I remember it correctly that with 'autofollow' refspec (valid only for tags... well, perhaps also for notes and replacements) you want to specify defaults in config explicitely

  [remote "origin"]
        url = git://git.example.com/repo.git
        fetch = +refs/heads/*:refs/remotes/origin/*
        fetch = ~refs/tags/*:refs/tags/*

Perhaps with

        fetch = +refs/heads/*:refs/remotes/origin/heads/*

Show 5 quoted lines

> 
> - 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?).

One of problems is how to keep the fact that

  $ git pull <URL> <branch>

does one-off pull without creating remote or remote-tracking branch. But I agree that behavior of

  $ git pull <remote> <branch>

can be confusing.

Show 7 quoted lines

>  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.

IMHO that's not inconsisnency in Git, this is just reflection of the fact that in most common case the situation is *assymetric* with respect to fetch and push; you fetch from other people repositories, but you push to (usually single, perhaps mirrored) your own publishing repository. For this situation 'push.default = matching' works perfectly.

Show 6 quoted lines

> 
> 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.

-- 
Jakub Narebski
Poland
ShadeHawk on #git