On 2016-06-04 07.14, Mike Hommey wrote: > On Fri, Jun 03, 2016 at 04:47:33PM -0700, Junio C Hamano wrote: >> Mike Hommey <mh@xxxxxxxxxxxx> writes: >> >>> In fact, the parser doesn't even reject the one that is considered >>> invalid (the first). >> >> My question was what the desired behaviour is, and if your "fix" >> gives us that desired outcome. > > From my POV, the desired outcome from this patch series is that there is > no change of behavior, and Torsten's fix makes > git://[example.com:123]:/path/to/repo urls handled the same before and > after the patch series. > > Whether that's the desired behavior is another topic, that we can, > IMHO, leave for later. This is the old behavior: GIT_TRACE=2 git clone -v git://[github.com:9418]:/tboegi/emacs.d.git $$ 16:32:28.692918 git.c:350 trace: built-in: git 'clone' '-v' 'git://[github.com:9418]:/tboegi/emacs.d.git' '95214' Cloning into '95214'... Looking up github.com:9418 ... fatal: Unable to look up github.com:9418 (port 9418) (nodename nor servname provided, or not known) # Everything inside [] goes into the host part (good), # At the same time :9418 is printed as the port (weird) This is the new behavior: GIT_TRACE=2 git clone -v git://[github.com:9418]:/tboegi/emacs.d.git $$ Connecting to github.com (port 9418) ... 192.30.252.122 done. or GIT_TRACE=2 git clone -v git://[github.com:9418]/tboegi/emacs.d.git $$ Connecting to github.com (port 9418) ... 192.30.252.122 done. In any case, everyting inside the [] should go into the host part, for all protocols that have a scheme. But. There is a little but. the ssh protocol did, in early days, not parse ssh://user@[::1]/path/to/repo correctly :-( The only workaround to use a user name with hostname in [] was to use ssh://[user@::1]/path/to/repo The thing I'm asking is, if we should handle git://[github.com:9418]/tboegi/emacs.d.git or git://[github.com:9418]:/tboegi/emacs.d.git the same as git://github.com:9418/tboegi/emacs.d.git -- 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