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

From: Daniel Barkalow <barkalow@iabervon.org>
Date: Sep 4, 2009, 15:40 UTC
Message-ID: <alpine.LNX.2.00.0909041114440.28290@iabervon.org>
In-Reply-To: <fabb9a1e0909032229k5e6e2ed5mc11e8ff9c16dfcc0@mail.gmail.com>

On Fri, 4 Sep 2009, Sverre Rabbelier wrote:

Show 12 quoted lines

> Heya,
> 
> On Fri, Sep 4, 2009 at 04:13, Daniel Barkalow<barkalow@iabervon.org> wrote:
> > Instead of trying to make http://, https://, and ftp:// URLs
> > indicative of some sort of pattern of transport helper usage, make
> > them a special case which runs the "curl" helper, and leave the
> > mechanism by which arbitrary helpers will be chosen entirely to future
> > work.
> 
> I'm sorry, I missed a few emails I think :(. Would you mind explaining
> why we chose to special-case the curl helpers instead of the symlink
> scheme?

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.

	-Daniel
*This .sig left intentionally blank*