Re: [PATCH 1/8] Make the "traditionally-supported" URLs a special case

Hi,

On Fri, 4 Sep 2009, Junio C Hamano wrote:

Daniel Barkalow [off-list ref] writes:

quoted

It turns out that the method used to form URLs that use a helper 
doesn't generalize well to other cases, because it interferes with the 
ssh-style locations. Instead, some different mechanism needs to be 
made up to handle arbitrary handlers that git doesn't know about. 
Since we want to keep supporting "http://something", that'll have to 
be a special case anyway, and so we might as well handle it by having 
git know what helpers to use for things that we've always supported, 
and use a single descriptive name for the helper that handles that 
collection of URLs.

As of this version, the idea is that there will be three ways helpers 
get selected:

 - git selects a helper based on the URL being something traditionally 
   supported internally; that is, git recognizes the URL and knows 
   what to run, if possible, to handle it

 - git uses the "vcs" option if it is set

 - something with the URL that we don't understand well enough yet to 
   design, but which doesn't seem to be possible to fit in as a single 
   rule with the first item.

Thanks for a clear description.

I do not see that there is much difference between the above description
and what Dscho is advocating, and I do not see anything to get excited
about as Dscho seems to do.

I mainly take exception at complicating things with a "vcs" config 
variable.

The way you describe it, I like it, as I do not see any mention of said 
config variable there.

If you allow "git clone <URL>" for foreign vcs URLs, you do not need the 
"vcs" variable.  If you require that variable, you cannot allow an easy 
clone, and you will earn my opposition.

Ciao,
Dscho