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

> Hi,
> 
> On Fri, 4 Sep 2009, Junio C Hamano wrote:
> 
> > Daniel Barkalow <barkalow@iabervon.org> writes:
> > 
> > > 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.