From: Junio C Hamano <hidden> Date: 2016-06-15 22:47:20
Daniel Barkalow [off-list ref] writes:
quoted
There was a discussion that suggests that the use of colon ':' before vcs
helper name needs to be corrected. Nothing happened since.
I believe the outcome of that discussion was:
- We want to keep supporting using regular location URLs that are URLs of
git repositories (e.g., http://git.savannah.gnu.org/cgit/xboard.git),
and we probably want to do it with a helper which runs when
run_command() is given "remote-<scheme>". I think installing hardlinks
in EXECPATH ended up being the best implementation here.
That is different from what I recall.
I think you said <scheme> in the above to mean that in the general URL
syntax, <scheme> refers to the token before the colon, and you would be
feeding the rest (i.e. after the colon, and for many <scheme>'s it
typically begins with //) to the scheme.
A flaw with this that was pointed out was that this conflicts with the
scp-like syntax. A remote.$name.url of foo:bar/baz could name
$HOME/bar/baz on host foo (perhaps a nickname in .ssh/config), or the
source "foo" helper recognizes with the name bar/baz.
If I recall correctly, suggestions made later in the discussion were to
use either <helper>+ or <helper>:: as the prefix to avoid this issue, and
use it to choose remote-<helper> (and I think I probably would vote for
double-colon, if only to avoid confusion with our own earlier misdesigned
syntax git+ssh://), so the canonical syntax would be:
<helper>::<whatever is fed to the helper, typicall a URL>
while we would support obvious short-hands for transports we traditionally
supported without explicit "<helper>::" prefix when we choose to eject it
from "built-in" set of transports.
E.g. http://git.savannah.gnu.org/cgit/xboard.git would be handled by curl
based walker, so if you spell it in the very canonical form, the url would
be curl::http://git.savannah.gnu.org/cgit/xboard.git, but nobody has to
use it. Instead, the transport dispatcher internally recognizes http://
and picks the curl based walker helper, which is remote-curl without any
extra hardlinks.
And from my point of view, this is what is blocking the series; and there
still is no -rc0 yet (I've been hoping to do a 1.6.5 mid September before
I leave for Japan for about a week), because I think it is pointless to do
a new release without "the ejection of curl from builtin".
- We want to support a separate "vcs" option for cases where repositories
in the foreign system need to be addressed through the combination of a
bunch of options, which will be read from the configuration by the
helper. The helper which gets run is "remote-<value of vcs option>".
This is in pu.
After you explained this in the thread (I think for the second time), I
see no problem with this, except that I think to support this we should
notice and raise an error when we see a remote has both vcs and url,
because the only reason we would want to say "vcs", if I recall your
explanation correctly, is that such a transport does not have the concept
of URL, i.e. a well defined single string that identifies the repository.
From: Daniel Barkalow <hidden> Date: 2016-06-15 22:47:20
On Sat, 29 Aug 2009, Junio C Hamano wrote:
Daniel Barkalow [off-list ref] writes:
quoted
quoted
There was a discussion that suggests that the use of colon ':' before vcs
helper name needs to be corrected. Nothing happened since.
I believe the outcome of that discussion was:
- We want to keep supporting using regular location URLs that are URLs of
git repositories (e.g., http://git.savannah.gnu.org/cgit/xboard.git),
and we probably want to do it with a helper which runs when
run_command() is given "remote-<scheme>". I think installing hardlinks
in EXECPATH ended up being the best implementation here.
That is different from what I recall.
I think you said <scheme> in the above to mean that in the general URL
syntax, <scheme> refers to the token before the colon, and you would be
feeding the rest (i.e. after the colon, and for many <scheme>'s it
typically begins with //) to the scheme.
A flaw with this that was pointed out was that this conflicts with the
scp-like syntax. A remote.$name.url of foo:bar/baz could name
$HOME/bar/baz on host foo (perhaps a nickname in .ssh/config), or the
source "foo" helper recognizes with the name bar/baz.
If I recall correctly, suggestions made later in the discussion were to
use either <helper>+ or <helper>:: as the prefix to avoid this issue, and
use it to choose remote-<helper> (and I think I probably would vote for
double-colon, if only to avoid confusion with our own earlier misdesigned
syntax git+ssh://), so the canonical syntax would be:
(with the syntax <helper>+, "git+ssh://" would specify the helper "git",
which is as good an explicit identifier of the internal handling as any)
<helper>::<whatever is fed to the helper, typicall a URL>
while we would support obvious short-hands for transports we traditionally
supported without explicit "<helper>::" prefix when we choose to eject it
from "built-in" set of transports.
E.g. http://git.savannah.gnu.org/cgit/xboard.git would be handled by curl
based walker, so if you spell it in the very canonical form, the url would
be curl::http://git.savannah.gnu.org/cgit/xboard.git, but nobody has to
use it. Instead, the transport dispatcher internally recognizes http://
and picks the curl based walker helper, which is remote-curl without any
extra hardlinks.
If the policy is that we're going to have "traditionally supported"
schemes, where the internal code knows what helper supports them, I can
fix up the series so that the curl-based helper is named "curl", and we
can say that the check for "http://", "ftp://", and "https://" is
recognizing traditionally-supported schemes, and we can defer coming up
with what the syntax for the explicit handler selection is. (For that
matter, if there's a // after the colon, it's obviously not a
handy ssh-style location, since the second slash would do nothing)
I think you're right that we decided that things we used to support
internally are a special case, and there's no need to try to generalize
them to be the general mechanism (even though I think we simultaneously
worked out how to implement the design we were abandoning, which confused
my memory).
quoted
- We want to support a separate "vcs" option for cases where repositories
in the foreign system need to be addressed through the combination of a
bunch of options, which will be read from the configuration by the
helper. The helper which gets run is "remote-<value of vcs option>".
This is in pu.
After you explained this in the thread (I think for the second time), I
see no problem with this, except that I think to support this we should
notice and raise an error when we see a remote has both vcs and url,
because the only reason we would want to say "vcs", if I recall your
explanation correctly, is that such a transport does not have the concept
of URL, i.e. a well defined single string that identifies the repository.
A user who mostly uses Perforce as a foreign repositories but is using a
SVN repo on occasion might want to use "vcs" regardless, but I agree with
forcing the helper to use a different option for the case of a URL that
git isn't going to look at. That is, you ought to be able to use:
[remote "origin"]
vcs = svn
(something) = http://svn.savannah.gnu.org/...
But "(something)" shouldn't be "url".
So my changes will be:
- name the curl-based helper executable "git-remote-curl", and run it for
traditionally supported schemes by special-case.
- prohibit using both "vcs" and "url" in a remote.
Agreed?
-Daniel
*This .sig left intentionally blank*
From: Junio C Hamano <hidden> Date: 2016-06-15 22:47:20
Daniel Barkalow [off-list ref] writes:
On Sat, 29 Aug 2009, Junio C Hamano wrote:
quoted
..., if only to avoid confusion with our own earlier misdesigned
syntax git+ssh://), so the canonical syntax would be:
(with the syntax <helper>+, "git+ssh://" would specify the helper "git",
which is as good an explicit identifier of the internal handling as any)
Sure but how would you explain "ssh+git://" then ;-)?
Luckily neither is advertised in our documentation set as far as I can
tell, so I do not think it is a huge deal between + vs ::, but as Peff
says in
http://thread.gmane.org/gmane.comp.version-control.git/125615
I think the latter is probably less problematic.
With plus, a helper that talks with a Subversion repository whose native
URL is http://host/path would look like svn+http://host/path, which is
reasonable. When talking the Subversion protocol over SSH, however, the
native URL for the repository would be svn+ssh://host/path, so the URL
with helper name on our side becomes svn+svn+ssh://host/path. We could
recognize "svn+" part and implicitly pass the whole thing to svn helper
upon seeing svn+ssh://host/path, but I do not think we would want to make
the dispatcher too familiar with what the backends do. Using something
other than plus sign would avoid this issue.
If the policy is that we're going to have "traditionally supported"
schemes, where the internal code knows what helper supports them, I can
fix up the series so that the curl-based helper is named "curl", and we
can say that the check for "http://", "ftp://", and "https://" is
recognizing traditionally-supported schemes, and we can defer coming up
with what the syntax for the explicit handler selection is. (For that
matter, if there's a // after the colon, it's obviously not a
handy ssh-style location, since the second slash would do nothing)
That sounds like a sane approach to first get the "eject curl from
builtin" out the door. We might extend the dispatcher in the future by
changing "traditionally supported" criterion to "commonly used",
e.g. recognize "svn+ssh://" as something the svn helper would want to
handle, but that is a future extension we do not have to address right
now.
quoted
After you explained this in the thread (I think for the second time), I
see no problem with this, except that I think to support this we should
notice and raise an error when we see a remote has both vcs and url,
because the only reason we would want to say "vcs", if I recall your
explanation correctly, is that such a transport does not have the concept
of URL, i.e. a well defined single string that identifies the repository.
A user who mostly uses Perforce as a foreign repositories but is using a
SVN repo on occasion might want to use "vcs" regardless, but I agree with
forcing the helper to use a different option for the case of a URL that
git isn't going to look at. That is, you ought to be able to use:
[remote "origin"]
vcs = svn
(something) = http://svn.savannah.gnu.org/...
But "(something)" shouldn't be "url".
I actuallly do not have a strong opinion on this one either way. I said
"I think" when I suggested it, but it was actually without thinking too
deeply, hoping that you would come up with a good counter-argument.
For example, if we envision that for most of the helpers there will be one
primary string that identifies the repository, but the primary string
alone is not enough for the helper without some auxiliary information, it
would be natural to use remote.$name.url for that primary string. I do
not know if that would be the case, but I was hoping that you would have a
better intuition[*1*], as you have thought this topic through a lot longer
and deeper than I have. So I'd rather leave the decision on that "no
vcs/url at the same time restriction" up to you. It is in general easier
to start more strict and then loosen the restiction later, than the other
way around, when we cannot decide, though.
Thanks.
[Footnote]
*1* What I mean by intuition is that you do not have to have the right
answer backed by research _now_, but have a good guess as to what the
right answer would be.
From: Daniel Barkalow <hidden> Date: 2016-06-15 22:47:20
On Mon, 31 Aug 2009, Junio C Hamano wrote:
Daniel Barkalow [off-list ref] writes:
quoted
On Sat, 29 Aug 2009, Junio C Hamano wrote:
quoted
..., if only to avoid confusion with our own earlier misdesigned
syntax git+ssh://), so the canonical syntax would be:
(with the syntax <helper>+, "git+ssh://" would specify the helper "git",
which is as good an explicit identifier of the internal handling as any)
Sure but how would you explain "ssh+git://" then ;-)?
That's just weird, and looks wrong to me, like ssh tunnelled over the git
native protocol. I think, if we support it, it would have to be another
special case.
Luckily neither is advertised in our documentation set as far as I can
tell, so I do not think it is a huge deal between + vs ::, but as Peff
says in
http://thread.gmane.org/gmane.comp.version-control.git/125615
I think the latter is probably less problematic.
With plus, a helper that talks with a Subversion repository whose native
URL is http://host/path would look like svn+http://host/path, which is
reasonable. When talking the Subversion protocol over SSH, however, the
native URL for the repository would be svn+ssh://host/path, so the URL
with helper name on our side becomes svn+svn+ssh://host/path. We could
recognize "svn+" part and implicitly pass the whole thing to svn helper
upon seeing svn+ssh://host/path, but I do not think we would want to make
the dispatcher too familiar with what the backends do. Using something
other than plus sign would avoid this issue.
I was thinking that the dispatcher would always pass the whole thing, and
the svn helper would have to deal with svn+http:// and svn+svn:// as well
as svn+ssh://. The dispatcher shouldn't be familiar with what the backends
do, but the backends could stand to be familiar with what might be there
just to get to them. On the other hand, I don't have a good intuition for
what makes sense to users of such systems, since I've only extensively
used cvs, git, and perforce.
quoted
If the policy is that we're going to have "traditionally supported"
schemes, where the internal code knows what helper supports them, I can
fix up the series so that the curl-based helper is named "curl", and we
can say that the check for "http://", "ftp://", and "https://" is
recognizing traditionally-supported schemes, and we can defer coming up
with what the syntax for the explicit handler selection is. (For that
matter, if there's a // after the colon, it's obviously not a
handy ssh-style location, since the second slash would do nothing)
That sounds like a sane approach to first get the "eject curl from
builtin" out the door. We might extend the dispatcher in the future by
changing "traditionally supported" criterion to "commonly used",
e.g. recognize "svn+ssh://" as something the svn helper would want to
handle, but that is a future extension we do not have to address right
now.
Fair enough.
quoted
quoted
After you explained this in the thread (I think for the second time), I
see no problem with this, except that I think to support this we should
notice and raise an error when we see a remote has both vcs and url,
because the only reason we would want to say "vcs", if I recall your
explanation correctly, is that such a transport does not have the concept
of URL, i.e. a well defined single string that identifies the repository.
A user who mostly uses Perforce as a foreign repositories but is using a
SVN repo on occasion might want to use "vcs" regardless, but I agree with
forcing the helper to use a different option for the case of a URL that
git isn't going to look at. That is, you ought to be able to use:
[remote "origin"]
vcs = svn
(something) = http://svn.savannah.gnu.org/...
But "(something)" shouldn't be "url".
I actuallly do not have a strong opinion on this one either way. I said
"I think" when I suggested it, but it was actually without thinking too
deeply, hoping that you would come up with a good counter-argument.
For example, if we envision that for most of the helpers there will be one
primary string that identifies the repository, but the primary string
alone is not enough for the helper without some auxiliary information, it
would be natural to use remote.$name.url for that primary string. I do
not know if that would be the case, but I was hoping that you would have a
better intuition[*1*], as you have thought this topic through a lot longer
and deeper than I have. So I'd rather leave the decision on that "no
vcs/url at the same time restriction" up to you. It is in general easier
to start more strict and then loosen the restiction later, than the other
way around, when we cannot decide, though.
Agreed.
Thanks.
[Footnote]
*1* What I mean by intuition is that you do not have to have the right
answer backed by research _now_, but have a good guess as to what the
right answer would be.
I don't really have a particularly good guess about the case of vcs and a
URL, because I haven't used systems that are not git and use URLs.
-Daniel
*This .sig left intentionally blank*