Hi, On Fri, 4 Sep 2009, Junio C Hamano wrote: > Daniel Barkalow <barkalow@xxxxxxxxxxxx> 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. Ciao, Dscho -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html