Re: remote#branch

From: Jeff King <peff@peff.net>
Date: Oct 31, 2007, 21:26 UTC
Message-ID: <20071031212655.GB13823@coredump.intra.peff.net>
In-Reply-To: <alpine.LFD.0.999.0710311350100.3342@woody.linux-foundation.org>

On Wed, Oct 31, 2007 at 02:01:54PM -0700, Linus Torvalds wrote:

Show 8 quoted lines

> > Yes, this means that if you have a bizarre repo name, you can't
> > necessarily switch between host:file syntax and git:// syntax by simple
> > cut and paste. But you really can't _anyway_, since there is no
> > guarantee that they are rooted at the same location, or have the same
> > view of the filesystem.
> 
> .. but in practice it works fine, especially for something like kernel.org 
> where it really *is* the same filesystem, just mirrored out.

Yes, and in practice, it works with or without URL encoding, since people aren't using names that need encoded.

> Also, more importantly, I think the quoting is *stupid*. It adds pointless 
> code for absolutely zero gain. Are you going to unquote '/'? Or how about 
> '~'?

I don't think it's zero gain; I think it's exactly what users who use repos with characters that need quoting will expect to happen. That being said, _I_ don't personally care that much since I think spaces in filenames are the work of the devil, and I will never use them. And as a result, I'm not going to implement the code to do it.

But I do think your argument that there is no value in the URL syntax is just wrong.

I don't understand your mention of '~' and '/'; they don't need quoted in URLs, and generally are not (though of course they can be).

> .. because it's a simple format, and it *works*. The same way INI config 
> files are simple and *work*.

But if you wrote a bunch of documentation referring to the git config file as an INI file, would you expect people to complain when it _didn't_ follow the usual expectation for INI files?

OK, this discussion is just getting nowhere, and there is useful git work I could be doing, so let me sum up my position:

  - We should either resolve that some repo specifiers are URLs, or we
    should resolve that they are not. I think they are.
  - If they are URLs, then we should treat them like URLs, and not
    handling quoting is probably a bug. I refuse to accept that it is an
    _important_ bug until somebody actually has a repo that needs
    quoting, finds that git is substandard, and provides a patch.
  - If they are not URLs, then we should probably stop calling them that
    in the documentation.

And with that, I shall say no more on the subject. In the spirit of not saying "oh, I don't want to talk about it anymore, you don't get to say anything else," I invite you to respond to any of my comments above.

-Peff