gitconfig includes

I just noticed something weird: if I have this in my ~/.gitconfig:

    [x]
      x = global
    [include]
      path = .gitconfig.more

and .gitconfig.more has

    [x]
      x = more

then I get:

1. git config x.x                      =>  more
2. git config --global x.x             =>  global
3. git config --global --includes x.x  =>  more

The first works as I expected. The second surprised me, since I took "--global" to mean "the global file and stuff it includes" (that's my understanding of the description of `include`). The third is fine, but it made me even more surprised at the second, especially since the man blurb on --includes says "Defaults to on."...

So this is at least a documentation issue, though I hope that #2 is a bug and that it *should* return "more"...?

Eli Barzilay <eli@barzilay.org> writes:

This already is documented, and I think it is clear enough.

       --[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.

On Tue, Nov 29, 2016 at 2:46 PM, Junio C Hamano <gitster@pobox.com> wrote:

Yeah, that's clear, sorry for not checking the latest.

[I'd expect/wish it to be on by default though... Any reason for the default being off in these cases?]

On Tue, Nov 29, 2016 at 02:53:08PM -0500, Eli Barzilay wrote:

It definitely needs to default to off for "-f", as we would not want surprises when accessing files like ".gitmodules" that come from untrusted sources.

I think it's arguable whether "--global" should behave the same. It makes the rule simple: "if you specify a single file, includes default to off". But I don't think there would be any particular harm. The existing default was mostly chosen for simplicity and least-surprise with respect to backwards compatibility.

There's a little more discussion in 9b25a0b52 (config: add include directive, 2012-02-06).

-Peff

Jeff King <peff@peff.net> writes:

I know you know this and I am writing this message for others.

I admit that I wondered if "a single file" ought to cover these short-hand notations like --global and --local while re-reading the log message of 9b25a0b52 (config: add include directive, 2012-02-06). In other words, I agree that it used to be arguable before we released v1.7.10.

It no longer is arguable simply due to backward compatibilty. The ship has long sailed.

On Tue, Nov 29, 2016 at 4:50 PM, Junio C Hamano <gitster@pobox.com> wrote:

I don't have any strong opinion, but FWIW, the use case I have for this is as follows: I sync my ~/.gitconfig between my own machine and a work machine. On the work machine though, I like people to have work emails, and I wrote some scripts that verify that. For my case, I added an include of a ~/.gitconfig.more which is not synced, and has values that override the ones in ~/.gitconfig. Since I'm the one who also wrote that script, I just added an "--includes" to the check so it won't barf on my setup, but had it not been my script I'd be stuck.

This is all a "FWIW" -- in case anyone thinks about use cases for a possible (future) change of the default.

On Wed, Nov 30, 2016 at 01:54:35PM -0500, Eli Barzilay wrote:

I'm not sure what your script does exactly, but in general I think the right thing for most scripts is _not_ to use a specific-file option like --global.

If the script is looking up a config value on behalf of a user, it probably makes sense for it to use the normal config lookup procedure (system, global, repo, command-line), which also enables includes by default. That would make it consistent with internal git config lookups (e.g., user.name probably only ever appears in global config, but you _can_ override it at the repo level if you want to).

I know that's mostly orthogonal to what we're discussing, but I'd feel more convinced that enabling "--includes" with "--global" is useful if I thought that "--global" was useful in the first place outside of a few narrow debugging cases.

-Peff

On Wed, Nov 30, 2016 at 2:06 PM, Jeff King <peff@peff.net> wrote:

This is intended for git newbies (and big company => infinite supply of them), and also allows them to conveniently nuke the repo and start from a fresh copy, so it makes sense to make the script inspect/tweak the global settings. If knowing git "well enough" was an assumed requirement, I'd definitely do the normal thing.

Ok. Perhaps I overestimated the utility of --global anyway, given the above...