Git Clone with 'file://' URLs Not Handled Properly

[jgehrig]

• I was not able to find an open or closed issue matching what I'm seeing

Setup

• Which version of Git for Windows are you using? Is it 32-bit or 64-bit?
  Windows 10 64-bit

$ git --version --build-options

git version 2.13.0.windows.1
built from commit: eba7af3dbb4c846c6303c5f64102acee696c9ab0
sizeof-long: 4
machine: x86_64

• Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?

$ cmd.exe /c ver

Microsoft Windows [Version 10.0.14393] 

• What options did you set as part of the installation? Or did you choose the
  defaults?

# type "C:\Program Files\Git\etc\install-options.txt"

Path Option: Cmd
SSH Option: OpenSSH
CURL Option: OpenSSL
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Performance Tweaks FSCache: Enabled
Use Credential Manager: Enabled
Enable Symlinks: Disabled

• Any other interesting things about your environment that might be related
  to the issue you're seeing?

Its not Linux? :(

Details

• Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

ConEmu/cmd.exe

• What commands did you run to trigger this issue? If you can provide a
  Minimal, Complete, and Verifiable example
  this will help us understand the issue.

$ git clone file://server/file/path/here
Cloning into 'here'...
fatal: 'C:/Program Files/Git/file/path/here' does not appear to be a git repository
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

• What did you expect to occur after running these commands?

Git should clone the files from \\servername\file\path\here

• What actually happened instead?

Git tries (and fails) to clone from C:\Program Files\Git\file\path\here

• If the problem was occurring with a specific repository, can you provide the
  URL to that repository to help us with testing?

This issue repros with any type of file:// style network path.

I can get this to work (manually) by using the syntax "git clone //servername/file/path/here", so this seems like an URL parsing error.

[shiftkey]

git clone file://server/file/path/here

I think there's a missing // after the file:// prefix - means the network path isn't rooted, which might explain why it's looking inside Program Files. What if you did file:////servername/file/path/here?

For example, this works for me from Git Bash:

$ git clone file://C:/users/shiftkey/src/some-repo foo
Cloning into 'foo'...
warning: You appear to have cloned an empty repository.

[jgehrig]

My understanding of the file:// standard is that file://host/filepath is the standard form for non local files. The part after file:// should denote the server, and in the local case it is null, hence file:///path/to/file.

See Section 3.10 https://www.ietf.org/rfc/rfc1738.txt

Either way, the 'C:\Program Files\Git' behavior seems like a bug?

I've never run personally across the 'file:////' style UNC paths before, but it looks like the format you suggest is mentioned in a few places, and may be an alternative standard. For example https://tools.ietf.org/html/draft-hoffman-file-uri-03. This syntax works for me as a workaround, thanks for the tip!

Also, technically your example should contain a third slash... Although having it work without the third slash is a good thing for usability. :)

$ git clone file:///C:/users/shiftkey/src/some-repo foo
Cloning into 'foo'...
warning: You appear to have cloned an empty repository.

[tboegi]

The syntax
git clone file://server/file/path/here
has never been supported by Git.
(and it is not mentioned in the documentation either)

The syntax for UNC path needs 4 slashes:
"file:////host.example.com/path/to/file"

And this is even suggested by a newer RFC:
https://tools.ietf.org/html/rfc8089#appendix-E.3

[jgehrig]

Thanks for the help!

I'm not blocked by this, I have converted a few URIs to file://// format, and everything works for me.

Not to get into a bug/feature war here... But I do think this is a bug. Git is non-compliant with part of the RFC standard. If this is a 'Won't Fix' issue, that is fine but I it should be called out somewhere in the form of a bug (here) or mentioned in the docs.

[shiftkey]

@tboegi @jgehrig if we can confirm this is also reproducible on non-Windows versions of Git, then it's a discussion that needs to be moved over to the Git mailing list.

[tboegi]

The Git documentation says:
For local repositories, also supported by Git natively, the following
syntaxes may be used:

• /path/to/repo.git/
• file:///path/to/repo.git/

---

So UNC path names are not mentioned at all.
Most people seem to use the syntax with 2 slashes:
//host.example.com/share/path/to/file

If someone wants to send a patch: This is welcome

[dscho]

This is not a WontFix issue, but it definitely shows once again that Git for Windows is not suffering a shortage of feature requests, but a shortage of volunteers to contribute improvements. @jgehrig please take this as an encouragement to work on a fix. I guess the best place to start would be here: https://github.com/git-for-windows/git/blob/v2.14.1.windows.1/connect.c#L616-L683 (most likely including the host part with two leading slashes in the returned path whenever appropriate).

[tboegi]

More by accident: I found an old patch, which I paste in here.
I personally use the UNC path //server/share/path/to/repo.git, so I will
not do anything more with this code.

commit d15e461708eb844002b24b29a2a2c95997ae0b93 (HEAD -> tb.160815-connect-UNC)
Author: Torsten Bögershausen tboegi@web.de
Date: Tue Aug 15 08:55:38 2017 +0200

Support UNC in git clone file://server/share/repo.git

Extend the parser to accept file://server/share/repo.git,
the way that some people want to specify UNC path under windows.

diff --git a/connect.c b/connect.c
index e78d3f43d8..b0947933c4 100644
--- a/connect.c
+++ b/connect.c
@@ -647,6 +647,8 @@ static enum protocol parse_connect_url(const char *url_orig, char **ret_host,
 
        if (protocol == PROTO_LOCAL)
                path = end;
+       else if (protocol == PROTO_FILE && (offset_1st_component(host-2) >=2))
+               path = host - 2; /* include the leading "//" */
        else if (protocol == PROTO_FILE && has_dos_drive_prefix(end))
                path = end; /* "file://$(pwd)" may be "file://C:/projects/repo" */
        else
diff --git a/t/t5500-fetch-pack.sh b/t/t5500-fetch-pack.sh
index 80a1a3239a..686c3a15a0 100755
--- a/t/t5500-fetch-pack.sh
+++ b/t/t5500-fetch-pack.sh
@@ -647,9 +647,12 @@ do
        # file with scheme
        for p in file
        do
-               test_expect_success "fetch-pack --diag-url $p://$h/$r" '
+               test_expect_success !MINGW "fetch-pack --diag-url $p://$h/$r" '
                        check_prot_path $p://$h/$r $p "/$r"
                '
+               test_expect_success MINGW "fetch-pack --diag-url $p://$h/$r" '
+                       check_prot_path $p://$h/$r $p "//$h/$r"
+               '
                # No "/~" -> "~" conversion for file
                test_expect_success "fetch-pack --diag-url $p://$h/~$r" '
                        check_prot_path $p://$h/~$r $p "/~$r"

[dscho]

Thanks, @tboegi!