From: Johannes Schindelin Date: Fri, 04 Sep 2009 18:02:25 GMT Subject: Re: [PATCH 1/8] Make the "traditionally-supported" URLs a special case Message-ID: In-Reply-To: <7vy6ouk4io.fsf@alter.siamese.dyndns.org> Hi, On Fri, 4 Sep 2009, Junio C Hamano wrote: > Daniel Barkalow 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 " 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