Git pushing to git remote with Windows file system URI fails

[DenzoNL]

Description
In my user folder on Windows (C:\Users\denzo\Code) I have a cloned git repository with the origin remote pointing to a bare git repository somewhere else on my C:\ drive on Windows. When accessing the cloned repository, both git remote show origin and git push throw an error.

Expected results
I was hoping that the file URI would be converted to a /mnt/c/ URI somewhere in the process by WSL.

Actual results (with terminal output if applicable)
Both git push and git remote show origin throw this same error.

$ git push
ssh: Could not resolve hostname c: Name or service not known
fatal: Could not read from remote repository.

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

Your Windows build number
Version 1607 (OS Build 14393.953)

Steps / All commands required to reproduce the error from a brand new installation
git push a commit on a cloned repository with a remote url pointing with a native Windows filesystem URI (e.g. C:\Repositories\myrepo.git)

Required packages and commands to install
git

[therealkenc]

I was hoping that the file URI would be converted to a /mnt/c/ URI somewhere in the process by WSL.

This would have to be made a Linux git feature (in the abstract hypothetical sense). WSL, at the point you run git remote show origin, does not "know" you are running git - it just processes the kernel syscalls the git ELF binary tells it to.

When Linux git parses your .git directory and sees the colon (:) in the remote origin string, it interprets it "badly" here. The Windows port of the git application (not the Windows OS) knows how to deal with such origin strings, but Linux git does not. In fact, on Real Linux™, "c" is a perfectly valid string to call your hostname, in which case (for example) git pull c:/myproject means pull myproject from the root directory of hostname "c" (ie from whatever IP address hostname "c" resolves). Linux git and the WSL kernel collectively don't know that isn't exactly what you meant. Instead, Linux git just tells you it can't find hostname "c".

So basically, there isn't any "somewhere in the process by WSL" for this seemingly natural behavior you want, except for doing it in the Linux git application itself, just like the Windows git port handles the case specially.

[aseering]

On that note, you might consider bringing this up with the git community:

https://git-scm.com/community

If I'm being realistic, I would kind of expect that they won't do anything about it, at least not quickly... But they definitely won't do anything about it if they don't know about it :-)

[therealkenc]

I think the Linux git people might say use Git BASH and never use the C:\ construct. Though I suppose I shouldn't purport to speak for them.

I think your #1854 (message) trick might fly:

• On the Win32 side, use Git BASH (aka MSYS) and always use forward slashes, which works on NTFS
• In Git BASH, create the bare git repository on /c/repo not C:\repo
• In Git BASH, pull it somewhere. Say /c/Users/denzo/projects/repo
• In WSL bash.exe, do sudo mount --bind /mnt/c /c
• Finally in WSL, do git remote show origin in /c/Users/denzo/projects/repo

Totally untested. You'll faceplant when you hit a symlink, but I digress.

[therealkenc]

I should add, at some risk of sounding like Captain Obvious, that you can start sshd on WSL and do git pull git@localhost:repo from either the Windows side or the WSL side. The bare repo should be in /home/git, not C:\, because you don't have permissions for C:\ in the first place. Unless you have made yourself a Windows Administrator. Which would be awfully sloppy.

[DenzoNL]

@therealkenc Thanks for the tip. The repository is not directly on the C:'\ root but exists in a synced folder there. It's a really bad practice, but unfortunately it is the way the company does things (didn't come up with it).

I'll have a go at trying those tricks tomorrow at work, it would be swell if I could commit from inside WSL.

Thanks!