Subject: RE: Why does the includeif woks how it does?

From: <[email-masked]>
Date: Mon, 19 Feb 2024 16:19:51 -0500

On Monday, February 19, 2024 3:10 PM, brian m. carlson wrote:
>On 2024-02-18 at 15:37:29, Dominik von Haller wrote:
>> 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?
>
>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.

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