Re: remote#branch

[Theodore Tso <tytso@mit.edu>]

On Mon, Oct 29, 2007 at 08:40:06PM -0700, Junio C Hamano wrote:
> Theodore Tso <tytso@mit.edu> writes:
> 
> > It would probably also be a good idea to expurgate URL's from the
> > documentations, because, well, they aren't URL's.  Git doesn't treat
> > them like URL's, and you've said you aren't interested in changing git
> > to treat them like URL's, and finally git:// isn't a registered URL
> > scheme name with the IANA registration authority.  So let's not call
> > them URL's, since they're clearly not.
> 
> Are you playing reverse psychology, encouraging us to switch to
> RFC-conforming quoting?

Well, URL's have a specific meaning and they're not for web browsing.
They are used to specify the addresses of printers, e-mail addresses,
LDAP servers, and much more.  Git is using something that looks like
URL's, but they they don't follow the URL rules.  So this brings up
interesting questions when a git webpage displayes something like
this (taken from repo.or.cz):

Mirror URL  git://repo.or.cz/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git
            http://repo.or.cz/r/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git
Push URL    git+ssh://repo.or.cz/srv/git/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git

Quick!  Which of the URL-like strings follow the URL quoting rules,
and which ones don't?  And if you have a character that must be quoted
in the pthname, should be quoted in in the http:// line?  And does it
matter if you are passing that URL-like string to a web browser or to
git-clone?

This is not language lawyering; this is a consistency issue that
matters.  But if Linus is going to say that git isn't going to follow
the URL quoting rules because it isn't a web browser, then clearly
what we are using aren't URL's.  So let's not *call* them URL's in our
documentation, because we're not following the URL rules.  That way is
only going to spawn more confusion.

Is this reverse psychology?  Well, I think git needs to pick whether
we operate on URL's or just things that *look* like URL's.  Either
way, the documentation should be specific about what's going on.  Me,
I'd prefer that git be liberal in what it accepts, and conservative in
what it sends.  That means that it would be useful if git could accept
URL's that are correctly quoted, and let things slide if characters
that should be quoted, aren't.  Git rarely actually emits URL's, and
mercifully people rarely use things like '#' characters in their
pathnames, so I don't think it would be that hard to make the
transition.

     	 	       	      	 	  - Ted