On Fri, 4 Sep 2009, Sverre Rabbelier wrote: > Heya, > > On Fri, Sep 4, 2009 at 04:13, Daniel Barkalow<barkalow@xxxxxxxxxxxx> 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* -- 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