Why does the includeif woks how it does?

Hi,

I have been playing around with the includeif from the .gitconfig. It did not work for me at first, but after some help, I did get it to work.

If you are curious. My Problem and what else was discussed here: https://github.com/git-for-windows/git/issues/4823

Anyway. So, I was trying to access the email property which was set through an includeif config. It did not work because I was in a non git directory. Yes, I do know that the property set in includeif is named gitdir, but it was not obvious to me that you need to be in a git tracked directory for it to work.

I am trying to understand why it must be this way. Why does it not work in non git tracked directories?

I am not sure if I am conveying my Question correctly. Please read the messages in the github issue if the content of this email was confusing.

Best regards Dominik von Haller

On 2024-02-18 at 15:37:29, Dominik von Haller wrote:

The main reason it works this way is because the goal is to adjust configuration based on the location of a repository. Thus, if I have `~/checkouts/work/` with my work code and `~/checkouts/personal/` with my personal code, I can set options that are appropriate in each case (e.g., `user.email`, `user.signingkey`, `credential.helper`, etc.).

Also, except for reading and writing with `git config`, the configuration is typically not used unless you're in a repository. There are only a handful of Git commands that don't use a repository at all, so usually setting configuration outside of a repository isn't very useful.

Note that if it didn't require a repository, then it would have to work on the current working directory. But, it should be noted, the gitdir option specifically does not operate on the current working directory. While it is customary to have one's working directory be inside the repository, you can be elsewhere and use `git -C` to change into the repository (internally, Git does indeed change the working directory, but that's an implementation detail).

That's not to say a feature couldn't be added that operated based on the current working directory (or some related constraint) instead, but no such feature has been added.

On Monday, February 19, 2024 3:10 PM, brian m. carlson wrote:

I have considered contributing an "includewhere" option that would do that and differentiate from "includeif". I'm not sure it is required, and what would happen with symbolic links.

Just a thought. --Randall

<rsbecker@nexbridge.com> writes:

Other potential gotchas would include how it interacts with directory hierarchies. You may be inside a directory /a/b (where none of /, /a, and /a/b is controlled by git) and want your "git init" invocation to be affected by some configuration included into your $HOME/.gitconfig via include-where mechanism. Would it work recursively? In other words, if you had

	[includeIf "gitdir:/a/b"] path = $HOME/gits/a-b-in-repo

	[includeIf "cwd:/"] path = $HOME/gits/others
	[includeIf "cwd:/a"] path = $HOME/gits/a
	[includeIf "cwd:/a/b"] path = $HOME/gits/a-b

would all of them be included? Just the last one? Does the most specific one win?

After your "git init" succeeds, the one specified with gitdir: would start kicking in. Would the "cwd:" ones that are meant for cases outside any directory under Git control be ignored then?

I am not opposed to such a feature existing at all; just pointing out there are sources of end-user confusion we need to be careful while we design the feature.