Patrick Steinhardt [off-list ref] writes:
- The naive way of just adding '@' as path separator would break
cloning repositories like '/foo/bar@baz.git' (which would
currently become 'bar@baz' but would become 'baz' only).
- Skipping the scheme initially is required because without it we
wouldn't be able to scan until the next dir separator in the
host part when stripping authentication information.
- First checking for '/' in the current stripped URI when we
want to remove the port is required because we do not want to
strip port numbers when cloning from something like
'/foo/bar:2222.git' (which would currently become '2222' but
would then be stripped of the ':2222' part and instead become
'bar'). Still, this breaks on cloning a bare repository in the
current dir (e.g. cloning 'bar:2222.git', which should become
'2222' because it is not a port number but would become
'bar').
This is a very good write-up.
Please make sure all of the above appears in the commit log message
somewhere.
As you can see, there is a lot of complexity in there and I'm not
convinced this is better than just exposing
'parse_connect_url()', which already handles everything for us.
If the function "handles everything for us", that's fine, but the
primary reason I am hesitant is because parse_connect_url() was
designed specifically not to have to worry about some protocols
(e.g. I think feeding it a "http://" would fail, and more
importantly, its current callers want such a call to fail). Also it
is meant to handle some non-protocols (e.g. scp style host:path that
does not follow <scheme>://...).
Also does it handle the "2222" case above? I do not think
parse_connect_url() even calls get_host_and_port() to be able to
tell what "2222" means in these examples.
Maybe I'm just being blind for the obvious solution here, though.
Patrick Steinhardt (6):
tests: fix broken && chains in t1509-root-worktree
tests: fix cleanup after tests in t1509-root-worktree
clone: do not include authentication data in guessed dir
clone: do not use port number as dir name
clone: abort if no dir name could be guessed
clone: add tests for cloning with empty path
builtin/clone.c | 67 ++++++++++++++++++++++++++++++++++++++++--------
t/t1509-root-worktree.sh | 51 +++++++++++++++++++++++++++++++++---
2 files changed, 103 insertions(+), 15 deletions(-)
On Wed, Aug 05, 2015 at 10:34:34AM -0700, Junio C Hamano wrote:
quoted
As you can see, there is a lot of complexity in there and I'm not
convinced this is better than just exposing
'parse_connect_url()', which already handles everything for us.
If the function "handles everything for us", that's fine, but the
primary reason I am hesitant is because parse_connect_url() was
designed specifically not to have to worry about some protocols
(e.g. I think feeding it a "http://" would fail, and more
importantly, its current callers want such a call to fail). Also it
is meant to handle some non-protocols (e.g. scp style host:path that
does not follow <scheme>://...).
True, but the transport code _is_ handling that at some point. It makes
me wonder if it would be possible to push the call to transport_get
further up inside cmd_clone(), and then provide some way to query the
remote path and hostname from the transport code. Then guess_dir_name
could just go away entirely, in favor of something like:
dir_name = transport_get_path(transport);
if (!*dir_name)
dir_name = transport_get_host(transport);
That may be overly simplistic or unworkable, though. I haven't dug into
the code.
Also does it handle the "2222" case above? I do not think
parse_connect_url() even calls get_host_and_port() to be able to
tell what "2222" means in these examples.
Speaking of which, has anyone tested whether the old or new code handles
external remote helpers? Certainly:
foo::https://host/repo.git
should still use repo.git. But technically the string handed to
git-remote-foo does not have to look anything like a URL. In those cases
neither guess_dir_name nor the transport code have any idea what anything
to the right of the "::" means; we probably have to resort to blind
guessing based on characters like colon and slash.
-Peff
On 2015-08-05 23.19, Jeff King wrote:
On Wed, Aug 05, 2015 at 10:34:34AM -0700, Junio C Hamano wrote:
quoted
quoted
As you can see, there is a lot of complexity in there and I'm not
convinced this is better than just exposing
'parse_connect_url()', which already handles everything for us.
I try expose and use parse_connect_url():
It handles the scp-like syntax "host:/path,
literall IPV6 addresses, port numbers,
':' without a port number and all other Git specific parsing,
which is inside and outside the RFC 3986.
(I should know, because I managed to break the parser twice,
and fix it)
I added a diagnostics to connect.c, and if you run the a simply test,
we can see that the colon slash logic is often unsufficient:
tb@mypc:~/projects/git/tb.150731_connect> ./git fetch-pack --diag-url ssh://host/
Diag: url=ssh://host/
Diag: protocol=ssh
Diag: userandhost=host
Diag: port=NONE
Diag: path=/
Diag: guesseddir=host/
tb@macce:~/projects/git/tb.150731_connect> ./git fetch-pack --diag-url ssh://host:/
Diag: url=ssh://host:/
Diag: protocol=ssh
Diag: userandhost=host
Diag: port=NONE
Diag: path=/
Diag: guesseddir=/
On top of that, you can easily write test cases in t5601, as many as you want.
The (minor) drawback is that it doesn't handle http:// or https://,
but that is easy to add in the parser, and doesn't break existing code.
The major which remains is to search for '@' in userandhost,
and strip that off.
(Or when there is a '@', search for a ':' before the '@', and strip that off)
After that, all non-printable characters should be %-escaped.
If we replace ':' as non-printable as well, we can make Windows users 1% more happy.
quoted
If the function "handles everything for us", that's fine, but the
primary reason I am hesitant is because parse_connect_url() was
designed specifically not to have to worry about some protocols
(e.g. I think feeding it a "http://" would fail, and more
importantly, its current callers want such a call to fail). Also it
is meant to handle some non-protocols (e.g. scp style host:path that
does not follow <scheme>://...).
True, but the transport code _is_ handling that at some point. It makes
me wonder if it would be possible to push the call to transport_get
further up inside cmd_clone(), and then provide some way to query the
remote path and hostname from the transport code. Then guess_dir_name
could just go away entirely, in favor of something like:
dir_name = transport_get_path(transport);
if (!*dir_name)
dir_name = transport_get_host(transport);
That may be overly simplistic or unworkable, though. I haven't dug into
the code.
quoted
Also does it handle the "2222" case above? I do not think
parse_connect_url() even calls get_host_and_port() to be able to
tell what "2222" means in these examples.
Speaking of which, has anyone tested whether the old or new code handles
external remote helpers? Certainly:
foo::https://host/repo.git
should still use repo.git. But technically the string handed to
git-remote-foo does not have to look anything like a URL. In those cases
neither guess_dir_name nor the transport code have any idea what anything
to the right of the "::" means; we probably have to resort to blind
guessing based on characters like colon and slash.
It is easy to strip the foo:: part of the url, assume that
the remote helper uses a RFC 3986 similar url syntax, so that we
can feed the reminding https://host/repo.git into the parser (see above).
If the remote helper doesn't do this, we can't guess anything, can we ?
So error out and tell the user seems the right thing to do.
In the hope that this is useful, pushed my prototype branch to
https://github.com/tboegi/git/tree/150731_connect_diag_guess_name