Re: remote#branch

On Tue, 30 Oct 2007, Tom Prince wrote:

Yes, for anonymous pulling.

The thing is, git takes something much more extended than a "RFC url".

We use pathnames. Not a "quoted mess". Regular, bog-standard, normal unix pathnames.

On Windows, I assume (and hope) that git uses the native-style Windows pathnames, and you can do "git pull d:\system\ugh" if you want to.

And I think we should care a whole lot about interacting with the *user* and actual programs that git shares code with, than interacting with some idiotic RFC that has absolutely zero to do with us, regardless of whether we use the name "url" or not.

For example, the reason we use "host:/path" for pushing over ssh (and pulling, for that matter), is that that's the same syntax that scp uses. It's a natural fit. And I hope to God nobody seriously argues that we shouldn't use regular pathnames on the local disk?

[ Btw, sorry for the french. I blame being tired and ina bad mood, but I 
  also blame the fact that I absolutely *detest* arguments based on 
  standards. If you cannot back it up with a real usage scenario, you 
  shouldn't even mention the standard ]

The way it has always cared. Git itself does no quoting what-so-ever (except for the *argument* quoting etc that it needs).

Now, the *transport* back-end may end up quoting it, of course, the same way it may end up using some random protocol. The user shouldn't care about the implementation details!

In the case of the git transport, there is no quoting even by the transport protocol. In the case of http, libcurl would hopefully quote for us.

No difference, what-so-ever, that I can see. Git doesn't quote it.

Notice how the fact that we use http:// doesn't actually mean that you can feed the result to a web browser anyway? It's not like you get a "link" that git follows. You get a name.

Yes, you can try to "co-locate" things so that something smart disambiguates (maybe have an "index.html" file, so a web browser gets a gitweb page, and git gets the raw data). But even then, notice how even web browser will do the quoting for you: try

	firefox "http://www.google.com/search?q=Html spaces"

just for fun.

Notice? The thing is, "strict RFC following" makes no sense:

 - the git syntax is (and HAS TO BE to be user friendly) a real extension 
   on any "strict RFC URL" anyway, since it is a lot more important to 
   interact well with normal unix tools (ie use regular filenames, and use 
   the same syntax as "cp", "mv" and "find" etc uses!)

   Ergo: we cannot and MUST NOT care about the "URL RFC" too deeply 
   anyway.

 - 

Git has been, and *is* entirely consistent. It uses convenient repo names. If you don't want to call them url's, then call them "repository name". Call them whatever. But they are 100% obvious, even if there are multiple forms of them (and *none* of the forms do any quoting at all):

 - <remote shorthand> ("origin")
 - <path> ("../git.git")
 - <host>:<path> ("master.kernel.org:/pub/scm/...")
 - <protocol>://<host>/<path> ("git://repo.or.cz/...")

See? We may not follow RFC's, but we follow "easy to use".

And btw, that's really much much MUCH more important. It's why the git config file is in a "ini"-like format. It's readable. It's not the insane RFC crap that would result if somebody had decided that standards are more important than being sane.

			Linus