Why does the includeif woks how it does?

Why does the includeif woks how it does?

[Dominik von Haller]

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

Re: Why does the includeif woks how it does?

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 2104 bytes --]

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.
-- 
brian m. carlson (he/him or they/them)
Toronto, Ontario, CA

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

RE: Why does the includeif woks how it does?

[rsbecker]

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

Re: Why does the includeif woks how it does?

[Junio C Hamano]

<rsbecker@nexbridge.com> writes:

> 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.

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.

Re: Why does the includeif woks how it does?

[Dominik von Haller]

Thanks, you all for your insights. <3


So to summarize, it was implemented through a gitdir because of possible confusions with the working directory. And there is no other implementation because the use case is not there.

For the new implementation I would always use the working directory. If set with git -C than use that. Should also not be a Problem because the working directory it is set internally anyway.


As far as the possible implementation of this goes, I would prefer an includeif with an extra option dir instead of gitdir. This would prevent confusion between includewhere and includeif.

The mentioned Problems seem to be easily figured out.
Every includeif == true will get included. Every more specific path will overwrite properties if set before. Gitdir is more specific than just dir.
Somewhat like that I would say is very intuitive.

Another possible approach which I would also say is logical is a top-down approach. Every Includeif would be executed from top to bottom. Every true includeif will be included and as before would overwrite properties if necessary. 


Best regards
Dominik von Haller