Re: What's cooking in git.git (Aug 2009, #05; Wed, 26)

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 30, 2009, 04:06 UTC
Message-ID: <7vskfat07h.fsf@alter.siamese.dyndns.org>
In-Reply-To: <alpine.LNX.2.00.0908292116060.28290@iabervon.org>

Daniel Barkalow <barkalow@iabervon.org> writes:

Show 10 quoted lines

>> 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-<scheme>". I think installing hardlinks 
>    in EXECPATH ended up being the best implementation here.

That is different from what I recall.

I think you said <scheme> in the above to mean that in the general URL syntax, <scheme> refers to the token before the colon, and you would be feeding the rest (i.e. after the colon, and for many <scheme>'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 <helper>+ or <helper>:: as the prefix to avoid this issue, and use it to choose remote-<helper> (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:

	<helper>::<whatever is fed to the helper, typicall a URL>

while we would support obvious short-hands for transports we traditionally supported without explicit "<helper>::" 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".

Show 5 quoted lines

>  - 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-<value of vcs option>". 
>    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.