git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Paul S. Strauss" <pss@acm.org>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org
Subject: Re: git config not following include paths by default
Date: Fri, 19 Jun 2020 11:50:40 -0700	[thread overview]
Message-ID: <3b4585dd-1d45-0631-f422-dfe13cc38a10@acm.org> (raw)
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


      reply	other threads:[~2020-06-19 18:50 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-18 20:25 git config not following include paths by default Paul S. Strauss
2020-06-18 20:40 ` Paul S. Strauss
2020-06-19 11:58   ` Jeff King
2020-06-19 18:50     ` Paul S. Strauss [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3b4585dd-1d45-0631-f422-dfe13cc38a10@acm.org \
    --to=pss@acm.org \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).