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. In his world, hg:// or any URL that begins with <unknown>:// wants to be a short-hand to name the helper, and the third rule whose detail is unspecified in the above list could be something like: - With an explicit <prefix-separator>, i.e. <helper-name> <prefix-separator> <any-string> tells the named helper git-remote-<helper-name> to interact with repository that it can find using <any-string>. We do not interpret, nor guess from, what <any-string> is, in this case. - When all else fails, and the URL looks like <unknown>://<any-string>, we see if git-remote-<unknown> is available and give it the whole string (including the <unknown>::// part). which means that what Dscho wants is already a subset of the future direction planned for this series. As to the "curl" indirection, if you consider the possiblity of someday adding the transparently backward compatible cgi based server with updated clients Gitney talked about, I am reasonably sure that we would want to have a new helper, say http-cgi, and have interested people invoke it using the "more explicit" escape hatch: $ git clone http-cgi::http://repo.or.cz/w/alt-git.git/ while others can continue using the walker via a plain http://repo.or.cz/ URL. When http-cgi helper proves to be successful and everybody's server upgrades, we might choose to swap the default, say in git 1.10.0 release, while leaving the door open for people to choose the old helper via an explicit curl::http://repo.or.cz/ URL. In short, from where I sit, I do not see much disagreement in the semantics and in the future direction between what Dscho is saying (unless I again misunderstood what he said) and what this round wants to bring. The only slight difference is that having an explicit excape hatch as the foundation, that usually does not have to be spelled out but does allow you to, keeps the concept cleaner, while keeping the usability of the end result. -- 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