Re: [PATCH 5/8] Add a config option for remotes to specify a foreign vcs

[Junio C Hamano <gitster@pobox.com>]

Daniel Barkalow <barkalow@iabervon.org> 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.