Why .gitconfig [includeIf] does not work?

Question

System settings: MacOS Catalina 10.15.6

> git --version
git version 2.24.3 (Apple Git-128)

file: ~/.gitconfig :

[user]
    name = nickname
    email = [email protected]
[includeIf "gitdir:~/Business"]
    path = ~/.gitconfig-work

file: ~/.gitconfig-work :

[user]
    name = First Last
    email = [email protected]

Output when trying to check the configuration on terminal:

(base) MBP-Name:~ myname$ cd ~/Business/
(base) MBP-Name:Business myname$ git config --get user.name
nickname

I have tried both relative ~ and absolute / paths either for gitdir and path in the config file. On each change I am restarting the bash. Also, I have read several other stackoverflow questions with no success. Some of them where suggesting adding the i option for case insensitivity but it didn't fix the problem.

Any ideas ?

Euler

Is ~/Business/ a repository (working tree)? If not hint: includeIf works only in repositories under ~/Business/ but not in a non-repo directory. – Paratyphoid

@Paratyphoid You were totally right. I had to change ``` "gitdir:~/Business"``` to ``` "gitdir:~/Business/"``` and hit the command inside a repo folder```. Thank you <3 – Euler

@Euler That's helpful. You should add it as an answer... :D – Whimper

Took me a few hours to figure out why it doesn't work. The overridden config will only be visible when you are in a git directory, otherwise it always shows the global values. – Incongruous

Had a similar issue to what author is describing, but with a different root cause. includeIf in global git config should be written AFTER user configuration. In my case, I had includeIf first thing in config and it didn't work – Spraddle

Answer 1

I know this is starting to be an old question, but I had a similar problem and the solution for it was dead simple, so I'll share it in case anyone has thee same problem: the problem was simply that your dir should have a slash (/) at the end...

So in the case of the OP,

[includeIf "gitdir:~/Business"]

Should simply become

[includeIf "gitdir:~/Business/"]

Hope this helps!

Ephemeron

This worked for me, the weird part is that the exact same config without the slash works on macOS, but on Linux you need the slash. – Denicedenie

Answer 2

I tried removing the double quotes and typing it again. weirdly it worked. since I copied the text from https://blog.gitguardian.com/8-easy-steps-to-set-up-multiple-git-accounts/

Beaujolais

This was the problem for me, the difference between the non-standard quote marks (“ ”) and standard quote marks (" "). Remove the fancy quote marks and its works – Fescennine

Exactly the same issue for me. Changed the "fancy" quote marks, and it worked well. – Mayest

Answer 3

I spent a lot of time trying to debug this but every time didn't work.

So I decided to delete and start fresh. This is what I did:

Create .gitconfig

[includeIf "gitdir:~/Documents/home/"]
path = ~/.gitconfig.home
[includeIf "gitdir:~/Documents/work/"]
path = ~/.gitconfig.work

Create .gitconfig.work

[user]
name = My Name
email My work email

Create .gitconfig.home

[user]
name = My Name
email My personal email

Then, I initialized git (git init) in both folders: ~/Documents/work/ and ~/Documents/home/.

After initializing everything work as expected.

I hope it helps you in case you are experiencing this issues.

Tested in Mac and Windows.

Gilmer

thanks for the help. the secret was git init on those folders – Melt

git init on the folder gets this working – Pinworm

Weirdly this isn't working for me. I had it set up with my home as default and work only applied to one area, but changed it to this setup to try to fix the issue, but no luck. All git commits have the correct user, but git push tries to use the wrong user. Even nuking the repo and re-cloning it didn't work. – Odometer

For anyone else having a similar issue I tracked down what it was: if you have an ~/.ssh/config file that sets a user name for your remote that will always take precedence over the git config. I.e. if you've set up an IdentityFile configuration for your remote, make sure you don't set the User property. – Odometer

It's especially hidden as for public repositories on GitHub the user won't matter for cloning, but it will for pushing. – Odometer

Thanks to this I realised why. includeIf only loads the config file if you are in a folder containing a git repository. It means, in a non-git folder which contains your custom .gitconfig, it does not get loaded. Just by doing git init you get the file loaded in further git commands. In my case I am using the core.sshCommand config to use a SSH private key depending on the folder structure to easily use multiple GitHub accounts. – Surra

Answer 4

I was trying to add both users to the same gitconfig file and it wasn't working for me. So, I created a gitconfig for each user and it worked!!

~/.gitconfig

[includeIf "gitdir/i:~/Documents/Personal/"]
    path = ~/.gitconfig_personal

[includeIf "gitdir/i:~/Documents/Work/"]
    path = ~/.gitconfig_work

~/.gitconfig_personal

[user]
    name = Your Personal Name
    email = [email protected]

~/.gitconfig_work

[user]
    name = Your Work Name
    email = [email protected]

Armin

Answer 5

I myself also had issues with my .gitconfig. I read the docs a few times, searched Stackoverflow and some blogposts. I though I have tried every possible solution for it: relative paths, trailing slashes, different quotes, et cetera. Non of the solutions I tried actually worked.

I got to the point I just tried to include a file using [include], but with no success either.

After a few hours of trying and searching for answers, I came across a post that mentioned a .gitconfig to be included could also be a .txt file. I changed the files from .gitconfig-{company} to gitconfig-{company}.txt and renamed the paths in the global .gitconfig, and everything worked instantly!

I hope this works for you, and future googlers.

Donegan

I think the .gitconfig file has to end in .gitconfig, like .github.gitconfig, which is what I use – Emprise

The global one does. But whenever I tried to import a file via the [includeIf], I needed to add the .txt extension in order to make it work. It took me a long time to figure out, since every example said it should just be .gitconfig-{company}. Maybe there is a setting enabled somewhere that causes my system to only check for .txt. Maybe someone also struggles with that and find that the .txt works for them too :) – Donegan

Did you try .{company}.gitconfig? – Emprise

Could try that. Thanks for the insight. The examples said it didn't matter , but it seems more logical that way. I just wanted to let you guys know that a .txt file also suffices. – Donegan

Answer 6

The answer to this question is the trailing '/' at the end of the dir. You'll see even when people did other things to 'fix it' they have added a trailing slash and don't even realize it.

Nietzsche

Your answer could be improved with additional supporting information. Please edit to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers in the help center. – Southwester

This does not provide an answer to the question. Once you have sufficient reputation you will be able to comment on any post; instead, provide answers that don't require clarification from the asker. - From Review – Burton

Answer 7

TL;DR

1. Make sure to test this includeIf business before assuming that it just works (just like anything else? 🤷‍♀️). It seems to not work (right away) in a lot of circumstances.
2. For some reason, git did not pick up the change until I use git config to make some random change. (Note: I am on win10)

Long Version

Firstly, make sure to look through the other answers in this post, since every post seems to contribute a different potential issue.

Now this is what happened to me (NOTE: I am on Windows 10):

1. Open ~/.gitconfig and add the entry includeIf entry
   • e.g.:

     [includeIf "gitdir:~/x/"]
     path = ~/.x.gitconfig
     

2. Create the custom ~/.x.gitconfig file and override some setting, e.g. set a.b = c (make sure its different from the default, so you can test it at first)
3. NOTE: This answer claims that this won't affect old directories, but I have not tested it.
4. Go to the directory (cd ~/x) and test. E.g. I tried git config a.b and it gave me the wrong value.
5. I realized the folder was not yet git inited, so I ran git init, and it still did not work.
6. Sln: I made a random local config change via git config some thing
7. Tested again and it worked and always picked up all changes immediately right after that. It now works!

Gasworks

Answer 8

Problem

In my case [includeIf] didn't work because my config is on the C: drive (C:\Users\User\.gitconfig), but my working projects are on the D: drive (D:\Projects\Work\).

Solution

In my case it should be:

[includeIf "gitdir/i:Work/"]

Instead of:

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

Documentation

Wainscot

Answer 9

Here is yet another reason why it would not work: If ~ is a link (and you use it in the condition). This is because when git computes the gitdir of a repo git rev-parse --git-dir, it gives the "realpath" of that directory with links resolved. If you have

[includeIf "gitdir:/a/link/c"]

and link -> target, even if the repo is in /a/link/c/d/repo, it won't go inside that section because git rev-parse --git-dir will give a/target/c/d/repo and that won't match a/link/c.

Example context

For example at work, the true location of my home dir is say

/storage/${my_department$}/${my_username}

for organizational purposes. We also have a flat directory containing links to the homes of every user.

/home/${my_username} -> /storage/${my_department$}/${my_username}

and in the entry in the passwd file is the link /home/${my_username} so my HOME environment variable gets set to that, and so ~ gets expanded to that as well.

I have

~/Repos/group_A/repo_{a1,a2,a3}
~/Repos/group_B/repo_{b1,b2,b3}

I had

[includeIf "gitdir:~/Repos/group_A"]
    path = ~/Repos/group_A/gitconfig_A
[IncludeIf "gitdir:~/Repos/group_B"]
    path = ~/Repos/group_B/gitconfig_B

which didn't work

Explanation

The above includeIfs did not work for e.g. ~/Repos/group_A/repo_a1 because its git dir was /storage/${my_department}/${my_username}/Repos/group_A/repo_a1 which did not match ~/Repos/group_A (since tilde expansion gives /home/${my_username}/group_A.

The gitdir does not start with ~/Repos/group_A

Solution

To solve this I'm refraining from using ~ and hardcoding the path with links resolved in the condition.

[includeIf "gitdir:/storage/${my_department}/${my_username}/Repos/group_A"]
    path = ~/Repos/group_A/gitconfig_A
[IncludeIf "gitdir:/storage/${my_department}/${my_username}/Repos/group_B"]
    path = ~/Repos/group_B/gitconfig_B

Note that I can still use ~ for the path = part because the problem only arises from the string comparison between a path with links expanded and one with links unexpanded.

Version controlled .gitconfig shared on different systems

This is kind of annoying since I version my .gitconfig and use it on multiple systems so hardcoded paths are not fun.

So what I did was to divide my .gitconfig in two, one that is versioned and one that is not

# .gitconfig (versioned)
[user]
    name = "Philippe Carphin"
#...

[include]
    path = ~/.gitconfig.specific

With the specific part all the way at the end so that the system specific stuff overrides the less specific stuff.

Manageable

Answer 10

I was also stuck by the strange behaviors after I use [includeIf "gitdir:~/foo"], it works sometimes, and sometimes doesn't.

Therefore I digged into Git's git-config official documentation Documentation:

gitdir

The data that follows the keyword gitdir: is used as a glob pattern. If the location of the .git directory matches the pattern, the include condition is met.

The .git location may be auto-discovered, or come from $GIT_DIR environment variable. If the repository is auto discovered via a .git file (e.g. from submodules, or a linked worktree), the .git location would be the final location where the .git directory is, not where the .git file is.

I personally feel this design is bizarre though... It means the [includeIf "gitdir:~/foo"] in your ~/.gitconfig can be triggered when you cd ~/foo/existed_project && git fetch though, BUT will not be triggered when you cd ~/foo && git clone, because the directory ~/foo/.git/ is not existed...

Explicitly setting env var GIT_DIR=~/foo seems also not work (maybe because ~/foo/.git is still not existed?).

As far as I know, a simpler workaround to solve this is to ~/foo && git init... I don't know if there's a better or canonical practice after DuckDuckGoing for hours.

Njord

Answer 11

I solved it by replacing ~ with absolute path , but i don't konw why. below is my config

[includeIf "gitdir/i:/Users/name/**"]
path = /Users/name/.gitconfig-personal
[includeIf "gitdir/i:/Users/name/Desktop/work/**"]
path = /Users/name/.gitconfig-work

[core]
excludesfile = ~/.gitignore

/Users/name/.gitconfig-work file like this

[user]
name = Jack
email = [email protected]

Chrysler

Answer 12

In my case, the problem was to expect git to overwrite some config sections of main .gitconfig in the others.

However, you need to explicitly set these configs in each git config file and should not set them in main .gitconfig file.

For instance, main .gitonfig file should not include user config if your .gitconfig-work and .gitconfig-personal users are different:

[user]
    name = Jane Does
    email = [email protected]
    signingkey = ...

Syncytium

I am having git overwrite user.email from ~/.gitconfig only for certain repos. At the top of my ~/.gitconfig, I have [user] email = <personal-email> and at the bottom [includeIf "gitdir:~/work-repos"] path = ~/work-repos/gitconfig which contains [user] email = <work email>. When I make commits in a work repo, the email is my work email and when I make commits in a non-work repo, the email is my personal email. They have to be in the right order. I tested it on git 2.42.0 and git 2.39 – Manageable

Answer 13

This will only affect future projects created with git init. Previous projects will remain unchanged

Gilleod

This does not provide an answer to the question. Once you have sufficient reputation you will be able to comment on any post; instead, provide answers that don't require clarification from the asker. - From Review – Aloha

Incorrect information – Deppy