It sure seems to be so... This is what git returns:

*** Please tell me who you are.

Run

  git config --global user.email "you@example.com"
  git config --global user.name "Your Name"

to set your account's default identity.
Omit --global to set the identity only in this repository.

fatal: unable to auto-detect email address (got 'eric@DESKTOP-7O2SA82.(none)')

What does git config --get-all user.name return, in that folder?

git config --get-all user.name returns Eric Williams in my personal folder and Eric Williams (my company name) in my work folder

This issue also effects me and I am using includeif in my global gitconfig.

Run

  git config --global user.email "you@example.com"
  git config --global user.name "Your Name"

to set your account's default identity.
Omit --global to set the identity only in this repository.

fatal: unable to auto-detect email address (got 'shadi@DRDIRTYLOVE.(none)')
> git config --get-all user.name
> git rev-parse --show-toplevel
fatal: Not a git repository (or any of the parent directories): .git

@joaomoreno any update on this issue? This is still friction for using the git integration in vscode.

@motowilliams I can't seem to reproduce this on macOS: I removed the user.name and user.email from my global .gitconfig, added the includeIf directive, verified that git config user.name picks up the name from the .gitconfig-personal, and tried to commit from VS Code: it worked fine.

$ code-insiders --version
1.24.0-insider
a521c01d56ec7f07bea2471880f28a77f37983af
x64
$ git --version
git version 2.15.1 (Apple Git-101)

is this a Windows specific issue? I'll try testing on Windows and Linux.

Edit: I can reproduce the issue on Windows 10 (1803) and Git for Windows 2.17. I have not tested on Linux. This may be a Windows specific issue.

@motowilliams I figured out the issue and have devised a workaround: VS Code passes a lowercase drive letter when launching Git, which somehow breaks the includeIf checking logic.

Thus, just use

[includeIf "gitdir/i:~/path/to/repo/"]

which enables case insensitive compare. This fixes the issue; I was able to commit successfully (Windows 10 1803, Git for Windows 2.17, Version 1.24.0-insider Commit a521c01 Date 2018-05-21T05:18:01.058Z)

I'm not sure whether the lowercase drive letter is coming from. I'll have to see how Git is launched on Windows.

How I found this:

I wrapped Git with a Batch file to see what was passed into Git:

@echo off
echo %* in %cd% >>"C:\Users\zhuowei\mygitlog%1.txt"
git config --list --show-origin >>"C:\Users\zhuowei\mygitlog%1.txt"
"C:\Program Files\Git\cmd\git.exe" %*

And set git.path in VSCode to use this executable. I tried to commit from VSCode, which failed to pick up the includeIf config. Then I ran the wrapper from the command line, and it did pick up the includeIf. I then checked the log:

In VSCode:

config --get-all user.name in c:\Users\zhuowei\Documents\repos\includeIf 

Outside:

config --get-all user.name in C:\Users\zhuowei\Documents\repos\includeIf

Note the difference in the case letter.

That means there's an actual workaround until releasing a new version of VSCode.

Use [includeIf "gitdir/i: in your .gitconfig file, so the include check will be case insensitive.

Can confirm the workaround of using case-insensitive gitdir ([includeIf "gitdir/i:) works, thanks @zhuowei !

Guys, I can't even get this working on my Windows machine, independent of VS Code. Here's my setup:

~/.gitconfig

[includeIf "gitdir/i:~/Work/vscode"]
	path = ~/.gitconfig-work
[includeIf "gitdir/i:~/Work/inno-updater"]
	path = ~/.gitconfig-personal

~/.gitconfig-personal

[user]
	name = Personal

~/.gitconfig-work

[user]
	name = Work

When running git config --get-all user.name from ~/Work/vscode in both Git Bash and the Command Prompt, git always returns and empty result and returns with 1.

What am I doing wrong?

@joaomoreno You need a trailing slash in the path.

Try:

[includeIf "gitdir/i:~/Work/vscode/"]

Thanks @zhuowei, that was it.

I really do think gitdir/i is not only the workaround but the actual proper way to do this. Since the FS is case insensitive, /i needs to be used instead of always changing the drive letter to a specific casing as #50376 attempts to do; this may and will have other consequences.

Closing this.