From: Junio C Hamano Date: Sun, 30 Aug 2009 04:06:10 GMT Subject: Re: What's cooking in git.git (Aug 2009, #05; Wed, 26) Message-ID: <7vskfat07h.fsf@alter.siamese.dyndns.org> In-Reply-To: Daniel Barkalow writes: >> There was a discussion that suggests that the use of colon ':' before vcs >> helper name needs to be corrected. Nothing happened since. > > I believe the outcome of that discussion was: > > - We want to keep supporting using regular location URLs that are URLs of > git repositories (e.g., http://git.savannah.gnu.org/cgit/xboard.git), > and we probably want to do it with a helper which runs when > run_command() is given "remote-". I think installing hardlinks > in EXECPATH ended up being the best implementation here. That is different from what I recall. I think you said in the above to mean that in the general URL syntax, refers to the token before the colon, and you would be feeding the rest (i.e. after the colon, and for many 's it typically begins with //) to the scheme. A flaw with this that was pointed out was that this conflicts with the scp-like syntax. A remote.$name.url of foo:bar/baz could name $HOME/bar/baz on host foo (perhaps a nickname in .ssh/config), or the source "foo" helper recognizes with the name bar/baz. If I recall correctly, suggestions made later in the discussion were to use either + or :: as the prefix to avoid this issue, and use it to choose remote- (and I think I probably would vote for double-colon, if only to avoid confusion with our own earlier misdesigned syntax git+ssh://), so the canonical syntax would be: :: while we would support obvious short-hands for transports we traditionally supported without explicit "::" prefix when we choose to eject it from "built-in" set of transports. E.g. http://git.savannah.gnu.org/cgit/xboard.git would be handled by curl based walker, so if you spell it in the very canonical form, the url would be curl::http://git.savannah.gnu.org/cgit/xboard.git, but nobody has to use it. Instead, the transport dispatcher internally recognizes http:// and picks the curl based walker helper, which is remote-curl without any extra hardlinks. And from my point of view, this is what is blocking the series; and there still is no -rc0 yet (I've been hoping to do a 1.6.5 mid September before I leave for Japan for about a week), because I think it is pointless to do a new release without "the ejection of curl from builtin". > - We want to support a separate "vcs" option for cases where repositories > in the foreign system need to be addressed through the combination of a > bunch of options, which will be read from the configuration by the > helper. The helper which gets run is "remote-". > This is in pu. After you explained this in the thread (I think for the second time), I see no problem with this, except that I think to support this we should notice and raise an error when we see a remote has both vcs and url, because the only reason we would want to say "vcs", if I recall your explanation correctly, is that such a transport does not have the concept of URL, i.e. a well defined single string that identifies the repository.