On Tue, 30 Oct 2007, Tom Prince wrote: > > The push url is generally written as > > > > repo.or.cz:/srv/git/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git > > > > Tough. > > But gitweb (on git.kernel.org and repo.or.cz) both give git:// locators. 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? > > Quick! WHO THE F*CK CARES? [ 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 ] > So, how should git deal with > > git://repo.or.cz/linux-2.6/linux acpi-2.6/ibm-acpi-2.6.git > git://repo.or.cz/linux-2.6/linux+acpi-2.6/ibm-acpi-2.6.git > git://repo.or.cz/linux-2.6/linux%20acpi-2.6/ibm-acpi-2.6.git 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. > compared to > > http://repo.or.cz/linux-2.6/linux acpi-2.6/ibm-acpi-2.6.git > http://repo.or.cz/linux-2.6/linux+acpi-2.6/ibm-acpi-2.6.git > http://repo.or.cz/linux-2.6/linux%20acpi-2.6/ibm-acpi-2.6.git 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. - > Not that I care, but git should probably handle things consistently. 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
