Thank you very much for your help.
I was trying to set up a dual-platform git configuration with a common (synced)
home directory structure.
I created gitconfig-linux and gitconfig-windows files that both include
gitconfig-common. (I would have done it the other way around if there was a
platform-based includeIf). Then I just set GIT_CONFIG to gitconfig-<platform> on
each system, which led to the problem.
I worked around it by linking ~/.gitconfig to the the platform-specific file on
each platform, but that is not ideal, IMO.
I didn't realize that using GIT_CONFIG was deprecated (or that it was equivalent
to specifying a file); there didn't seem to be a better way to do what I wanted.
- Paul
On 6/19/20 4:58 AM, Jeff King wrote:
On Thu, Jun 18, 2020 at 01:40:11PM -0700, Paul S. Strauss wrote:
The problem is related to my having GIT_CONFIG set to a file other than
~/.gitconfig - when I unset GIT_CONFIG and copied my config file to
~/.gitconfig, the include worked as expected.
That's working as designed. From git-config(1):
--[no-]includes
Respect include.* directives in config files when looking up
values. Defaults to off when a specific file is given (e.g.,
using --file, --global, etc) and on when searching all config
files.
The reasons for that are historical. Includes were added much later, and
you would probably not want "git config --file=.gitmodules" against an
untrusted input to be able to include from anywhere on your filesystem.
$GIT_CONFIG works the same way (as it's equivalent to using --file). We
generally discourage the use of the environment variable (and its
existence is yet another historical compatibility thing). If you tell us
more about what you're trying to accomplish with it, we might be able to
suggest a better solution.
-Peff
--
Paul S. Strauss pss@xxxxxxx
