Re: git config not following include paths by default
- From
- Paul S. Strauss <pss@acm.org>
- Date
- Jun 19, 2020, 18:50 UTC
- 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:
Show 24 quoted lines
> 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