From: Paul S. Strauss <pss@acm.org>
Date: Fri, 19 Jun 2020 18:50:40 GMT
Subject: Re: git config not following include paths by default
Message-ID: <3b4585dd-1d45-0631-f422-dfe13cc38a10@acm.org>
In-Reply-To: <20200619115859.GA1835585@coredump.intra.peff.net>

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@acm.org