Daniel Barkalow <barkalow@xxxxxxxxxxxx> writes: > If this is set, the url is not required, and the transport always uses > a helper named "git-remote-<value>". > > It is a separate configuration option in order to allow a sensible > configuration for foreign systems which either have no meaningful urls > for repositories or which require urls that do not specify the system > used by the repository at that location. However, this only affects > how the name of the helper is determined, not anything about the > interaction with the helper, and the contruction is such that, if the > foreign scm does happen to use a co-named url method, a url with that > method may be used directly. Personally, I do not like this. Why isn't it enough to define the canonical remote name git takes as "<name of the helper>:<whatever string the helper understands>"? Then <whatever string the helper understands> part does not have to resemble URL at all, if the foreign system does not have such a concept (i.e. "have no meaning urls for repositories"). Your "let's eject curl based transport out of core" helper (already in 'next') will become something like these in the canonical form: curl:http://git.kernel.org/pub/scm/git/git.git curl:ftp://git.kernel.org/pub/scm/git/git.git curl:https://git.kernel.org/pub/scm/git/git.git that are handled by a single helper binary git-remote-curl, but nobody has to use these canonical forms for well-known transports, because we can have an obvious set of backward-compatible synonyms that are understood by the transport layer to choose that helper program, so that usual http://git.kernel.org/pub/scm/git/git.git will be understood to choose git-remote-curl backend. We do not need to have three git-remote-{http,https,ftp} helpers at all. That way, a Subversion repository people may want to interact with would be spelled, if the helper is "git-remote-svn", like this: svn:https://scummvm.svn.sourceforge.net/svnroot/scummvm/ and it would be crystal clear that it is not a git native repository that is accessed over curl based walkers, and also the folks who still have not migrated to git can simply drop the leading "svn:" and learn the name of the repository they could access natively with Subversion. Nobody on the Subversion side would think svn:https://... is the URL to use with Subversion (after all they will see that on the communication in the git circle). And from the git side, we can tell users: "if you want to interact with Subversion repositories, you can use traditional git-svn, or you can use the unified remote mechanism. To use the latter, just prefix 'svn:' in front of the URL used to refer to the repository in the Subversion world". If you spell the "URL" as https://scummvm.svn.sourceforge.net/svnroot/scummvm/ then you wouldn't be able to give that directly to git from the command line, without using this new configuration. I do not quite understand why this indirection is desired. I think it only confuses users. I recall somebody earlier mentioned a possibility to have more than one helper that deals with one type of foreign system. In such a case, a pair of URL and vcs configuration can be used to identify what helper to use on what foreign "repository": (https://scummvm.svn.sourceforge.net/svnroot/scummvm/, svn) (https://scummvm.svn.sourceforge.net/svnroot/scummvm/, svn-ng) and it might become easier to switch the helper without changing the URL part. But I do not particularly think that would be a practical advantage, unless we can assume that the next-generation version of the helper can somehow reuse the metadata the old version of the helper left in the repository and incrementally operate on the repository. Even in that case, I think spelling everything out in a single configuration (i.e.. remote.$name.url) would make it clearer to see what is going on. -- 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