Warnings about /unix/like/paths on Windows

[sferencik]

• 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?

$ git --version --build-options

git version 2.38.1.windows.1
cpu: x86_64
built from commit: b85c8f604d375d4d773a36842964e8a7ec056aae
sizeof-long: 4
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon
warning: encountered old-style '/home/' that should be '%(prefix)//home/'
warning: encountered old-style '/Users/' that should be '%(prefix)//Users/'

• 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.19044.2251]
warning: encountered old-style '/home/' that should be '%(prefix)//home/'
warning: encountered old-style '/Users/' that should be '%(prefix)//Users/'

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

# One of the following:
> type "C:\Program Files\Git\etc\install-options.txt"
> type "C:\Program Files (x86)\Git\etc\install-options.txt"
> type "%USERPROFILE%\AppData\Local\Programs\Git\etc\install-options.txt"
> type "$env:USERPROFILE\AppData\Local\Programs\Git\etc\install-options.txt"
$ cat /etc/install-options.txt

Editor Option: VIM
Custom Editor Path:
Default Branch Option:
Path Option: Cmd
SSH Option: OpenSSH
Tortoise Option: false
CURL Option: OpenSSL
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Git Pull Behavior Option: Merge
Use Credential Manager: Enabled
Performance Tweaks FSCache: Enabled
Enable Symlinks: Enabled
Enable Pseudo Console Support: Disabled
Enable FSMonitor: Disabled
warning: encountered old-style '/home/' that should be '%(prefix)//home/'
warning: encountered old-style '/Users/' that should be '%(prefix)//Users/'

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

Not aware of anything relevant.

Details

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

ConEmu. Reproducible in Git Bash, Powershell.

• 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 status

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

Expected git status output, starting with On branch main etc.

• What actually happened instead?

The git status output is prefixed by warnings:

$ git status                                                                 
warning: encountered old-style '/home/' that should be '%(prefix)//home/'    
warning: encountered old-style '/Users/' that should be '%(prefix)//Users/'  
warning: encountered old-style '/home/' that should be '%(prefix)//home/'    
warning: encountered old-style '/Users/' that should be '%(prefix)//Users/'  
warning: encountered old-style '/home/' that should be '%(prefix)//home/'    
warning: encountered old-style '/Users/' that should be '%(prefix)//Users/'  
warning: encountered old-style '/home/' that should be '%(prefix)//home/'    
warning: encountered old-style '/Users/' that should be '%(prefix)//Users/'  
warning: encountered old-style '/home/' that should be '%(prefix)//home/'    
warning: encountered old-style '/Users/' that should be '%(prefix)//Users/'  
warning: encountered old-style '/home/' that should be '%(prefix)//home/'    
warning: encountered old-style '/Users/' that should be '%(prefix)//Users/'  
warning: encountered old-style '/home/' that should be '%(prefix)//home/'    
warning: encountered old-style '/Users/' that should be '%(prefix)//Users/'  
warning: encountered old-style '/home/' that should be '%(prefix)//home/'    
warning: encountered old-style '/Users/' that should be '%(prefix)//Users/'  
warning: encountered old-style '/home/' that should be '%(prefix)//home/'    
warning: encountered old-style '/Users/' that should be '%(prefix)//Users/'  
warning: encountered old-style '/home/' that should be '%(prefix)//home/'    
warning: encountered old-style '/Users/' that should be '%(prefix)//Users/'  
warning: encountered old-style '/home/' that should be '%(prefix)//home/'    
warning: encountered old-style '/Users/' that should be '%(prefix)//Users/'  
warning: encountered old-style '/home/' that should be '%(prefix)//home/'    
warning: encountered old-style '/Users/' that should be '%(prefix)//Users/'  
On branch main                                                               
Your branch is ahead of 'origin/main' by 1 commit.  
...                         

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

Affects all the repos.

[sferencik]

The warnings come from my ~/.gitconfig, which contains includeIf directives. Specifically, I use the following to include OS-specific git configuration:

[includeIf "gitdir:/home/"]
    path = ~/.gitconfig-linux
[includeIf "gitdir:/Users/"]
    path = ~/.gitconfig-mac
[includeIf "gitdir:C:"]
    path = ~/.gitconfig-windows

See here for an explanation of this usage. In short: if the repo root is under /home/, let's assume we're on Linux and load ~/.gitconfig-linux with the Linux-specific git configuration; if the repo root is under C:, we're on Windows and we load ~/.gitconfig-windows.

This worked well until (I believe) commit 66a6bcf. Following this change, when POSIX paths (like /home/) are encountered on Windows, a warning is issued. In either case (i.e. both before and after the commit) the path is then converted to [runtime prefix]\home\ (as I just learned from the commit description). This is fine for me: on Windows, my repos are never under [runtime prefix]\home\ (nor are they under C:\home\) and so the Linux-specific git config is not loaded.

I really wish there was a way to silence these warnings. Notice how they pepper the output of every git command.

https://github.com/git-for-windows/build-extra/blob/main/ReleaseNotes.md#git-for-windows-v2353-release-notes says:

Alternatively, you can double the first slash to avoid POSIX-to-Windows path conversion, e.g. "//usr/bin/bash.exe".

Maybe at least the warning shouldn't be issued if the path starts with //? I'd be happy to change my includeIf paths to //home and //Users (I'm assuming git on Linux and Macos would handle this well) if it removed the warning on Windows.

[dscho]

This warning comes from https://github.com/git-for-windows/git/blob/v2.38.1.windows.1/path.c#L742-L747 (it was first introduced in v2.34.0, which is just over a year old).

Since it has been over a year (if only just that), I guess we could now remove that warning. That would have two downsides, though. Users who haven't updated in over a year and who rely on the old "/something should expand to C:/Program Files/Git/something" functionality would

1. miss that deprecation warning
2. potentially end up with a broken setup without even noticing that it is broken for a very long time

I also fear that the conditions in your ~/.gitconfig are a bit fragile. Not that I want to discourage you from using them, but who's to say that the repository is always hosted on the C: drive? Also, are you sure that it works? From reading https://git-scm.com/docs/git-config#Documentation/git-config.txt-codegitdircode, I would have assumed that you's need gitdir/i:C:/.

A much more robust approach would be to implement an Operating System-specific includeIf condition, which is what I implemented over here: gitgitgadget#1429

[PhilipOakley]

On 21/11/2022 07:46, Johannes Schindelin wrote: A much more robust approach would be to implement an Operating System-specific includeIf condition, which is what I implemented over here: gitgitgadget#1427 <gitgitgadget#1427>

(for those seeing the notification emails) It's moved to gitgitgadget#1429 for 'reasons' . Philip

[sferencik]

Thank you, @dscho, that's great. An includeIf conditional on the OS is absolutely the superior option.

Some notes:

• You're right that the commit introducing the warnings is older. I just haven't updated my git for Windows for a while (or in fact worked on Windows at all). I don't have opinion on how long you should give everyone before breaking that backward compatibility.
• The OS-based check will do for me (I should say it will work fantastically!). What's your plan with this issue after that? Is there still something to be done here about the warnings? Maybe support paths with leading //? Perhaps there's a real case there because those paths were never implicitly handled as relative to the runtime root.
• Yes, gitdir:C: works for me: the Windows specific file is being sourced (only on Windows).
• You're spot on about the fragility of the paths-based solution. There's a Linux system I work on, where /home/ is not a thing and for that I need one more includeIf section. I just took it out for the purpose of describing the issue. That's also the answer to your question of "what if there are other paths or Windows drives?": if that's the case, you're forced to enumerate them all in the git config.
• As a further inconvenience, the path-based includeIf asks about the git dir. I.e. the question isn't "Are we on a system that has a /home (or C:)?" but rather "Is this specific repo somewhere under /home (or C:)?" That makes this even less practical for solving OS-specific includes because you really need to list all the places where your repos may be on the filesystems. I believe the other question has been discussed before (includes conditional on the existence of a path) but I cannot find it now. This has come up as I searched, as pre existent related work. Just fyi.

Thank you so much for the quick turnaround!

[sferencik]

Adding to the last point: this implies that the conditional includes (based on gitdir) don't work at all until/unless you're in a git dir. So git init and git clone frustratingly don't get my OS specific config (even if I run them under /home). Stack overflow has many questions on this.

Just listing this as one more way in which your solution is the superior one.

[dscho]

I could merge this fairly quickly into Git for Windows, once upstream indicates that it'll accept the patch.

The problem is that you'll need this on other platforms, too, otherwise it'll be useless 😁

[sferencik]

@dscho What next with your commit? Do you want to make a PR? Should I? I'm happy to help to see this resolved.

[dscho]

Do you want to make a PR?

I already did: gitgitgadget#1429

I even submitted it to the Git mailing list, where the Git maintainer suggested that "os" is not a good name for this, and "uname-s" would be a better name.

That suggestion, quite frankly, shocked me. If you find "os" a better name than "uname-s" (or "sysname"), you may want to reply to that thread (see GitGitGadget's tips on replying to existing threads on the Git mailing list) and either come out in favor of "os", or in favor of any suggested alternative, or even come up with a better suggestion.

At this point, I am rather one hundred percent certain that "uname-s" and "sysname" would be terrible, terrible choices because they are so unintuitive that I fail to understand how those suggestions could even have been uttered in all seriousness. That's why I did not pursue the patch any further.

[sferencik]

Thanks, yes, now I remember. Appreciate it.

People care about naming, and that's a good thing. I'll try to revive that conversation. Surely we can reach a consensus rather than stall the whole PR.