[Bug report] includeIf config is not displayed in normal directories

Hello,

I've seen this thread: https://public-inbox.org/git/F55DC360-9C1E-45B9-B8BA-39E1001BD620@gmail.com/t/#u

and respectfully disagree with the conclusion. Conditionally included configuration can contain items like core.sshCommand that are required for git clone while in a normal non-git directory. These should be displayed properly so users know what configuration they are operating with.

Also, conditionally included config is acted upon despite not being displayed. This makes tracking down problems much more difficult.

Further, most complaints online are about user.name and user.email not being displayed correctly. If those items are in ~/.gitconfig, then they are displayed in a normal non-git directory by normal git config commands. This makes conditionally included configuration display inconsistent with regular configuration display. Inconsistency is bad and should be fixed.

See 'git bugreport' attached for further information, reproduction steps, etc.

Thanks, ...Stu

Thank you for filling out a Git bug report! Please answer the following questions to help us understand your issue.

What did you do before the bug happened? (Steps to reproduce your issue)

Set up a conditional include:
vvvvvvvvvv [ ~/.gitconfig ] vvvvvvvvvv
[includeIf "gitdir:~/work/"]
	path = ~/.gitconfig-work
^^^^^^^^^^ [ ~/.gitconfig ] ^^^^^^^^^^

vvvvvvvvvv [ ~/.gitconfig-work ] vvvvvvvvvv
[user]
	name = Stuart MacDonald
	email = stuartm.coding@gmail.com
[core]
	sshCommand = "ssh -i ~/.ssh/id_rsa.stuartm_github"
^^^^^^^^^^ [ ~/.gitconfig-work ] ^^^^^^^^^^

Make sure ssh is configured properly for github access:
vvvvvvvvvv [ ~/.ssh/config ] vvvvvvvvvv
Host github github.com
  Hostname github.com
  User git
  IdentitiesOnly yes
^^^^^^^^^^ [ ~/.ssh/config ] ^^^^^^^^^^

Run the following commands in a Git bash shell: $ mkdir ~/work/git-bug-test $ cd ~/work/git-bug-test $ git config --show-origin --get-all core.sshCommand OBSERVE A: There is no output $ git clone --recursive git@github.com:git/git.git OBSERVE B: The clone succeeds $ cd git $ git config --show-origin --get-all core.sshCommand file:C:/Users/stuartm/.gitconfig-work ssh -i ~/.ssh/id_rsa.stuartm_github OBSERVE C: The configuration item is displayed $ cd .. $ git config --show-origin --get-all core.sshCommand OBSERVE D: There is no output

NOTE: In the above reproduction steps I've substituted my work email and
employer's private respository (which needs the approrpriate ssh key to be able
to clone) for my public email and a public repository. This means my
reproduction steps aren't an exact reproduction; for an exact reproduction
please substitute an email address and private repository that requires a
configured ssh key to clone.

What did you expect to happen? (Expected behavior)

I expected OBSERVE A and OBSERVE D to match OBSERVE C's output.

What happened instead? (Actual behavior)

There was no output.

What's different between what you expected and what actually happened?

Output vs no output.

Anything else you want to add:

I spent a lot of time yesterday tracking down a problem with my git configuration that was preventing me from checking out private repositories. The incorrect "no output" bug caused me to think I had some issue with my conditional configuration setup and I was trapped in that dead end for too long.

It seems that includeIf is not widely discussed online. This makes it difficult to find help. I did find https://stackoverflow.com/questions/43919191/git-2-13-conditional-config-on-windows which says in part "If its [sic] not git initialized then the includeIf gitdir functionality will not work." which is actually inaccurate. It does function; commenting out/in the sshCommand configuration line causes cloning to not work or work from a normal directory.

Additionally, moving the sshCommand config item into ~/.gitconfig will cause OBSERVE A and OBSERVE D to produce output. This clearly implicates includeIf processing as the problem.

I've seen this thread https://public-inbox.org/git/F55DC360-9C1E-45B9-B8BA-39E1001BD620@gmail.com/t/#u and I understand that some config items don't make sense in a normal directory. However, some do, critically core.sshCommand. Also, if user.name is in the top level (non-conditional) .gitconfig, then it is reported by git config in a normal directory whether that makes sense for a normal directory or not.

The minimum fix I'd like to see: conditional includes should be processed and any configuration items for which use in a normal directory makes sense should be present and reported properly. Again, critically, this includes core.sshCommand.

The better fix is to have conditional include processing be at parity with direction configuration; where a configuration item would be displayed if it was in a top-level/direct .gitconfig file, then it should also be displayed if it's conditionally-included. This would make the config system consistent, which is important for ease of use. I realise this goes against the sentiment in the git mailing list thread I linked above. I believe that thread is wrong in its conclusion of "working as designed".

Please review the rest of the bug report below. You can delete any lines you don't wish to share.

[System Info] git version: git version 2.29.2.windows.2 cpu: x86_64 built from commit: 3464b98ce6803c98bf8fb34390cd150d66e4a0d3 sizeof-long: 4 sizeof-size_t: 8