On Tue, Oct 30, 2007 at 07:59:45 -0700, Linus Torvalds wrote: > > 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. So the three addresses will all be different, right? > > 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. Yes. But the server will unquote it. ' ' should not have been there, but it's just passed through if it was. '+' is quoting for ' ' and '%20' is quoting for ' ' as well. Therefore all these three addresses are the *SAME*. Now the user expectation will be that when these are the same, the git:// ones above will be as well. But they are not. This is not about following any RFC for sake of it, but about being consistent with ourselves. > 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. Sure. There is no abiguity in decoding this, so why refuse it. > [...] > - ("origin") > - ("../git.git") > - : ("master.kernel.org:/pub/scm/...") > - :/// ("git://repo.or.cz/...") > > See? We may not follow RFC's, but we follow "easy to use". The first three don't look like URL ("URL" always means the thing defined by RFC 2396, at least to me), so I don't expect any quoting there. But for the last case http:// (and for that matter, sftp://) do use quoting, so I would expect the quoting of something that differs only by starting with git:// to work the same. -- Jan 'Bulb' Hudec