gitconfig includes

gitconfig includes

[Eli Barzilay]

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"...?

-- 
                   ((x=>x(x))(x=>x(x)))                  Eli Barzilay:
                   http://barzilay.org/                  Maze is Life!

Re: gitconfig includes

[Junio C Hamano]

Eli Barzilay <eli@barzilay.org> writes:

> So this is at least a documentation issue,...

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.

Re: gitconfig includes

[Eli Barzilay]

On Tue, Nov 29, 2016 at 2:46 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Eli Barzilay <eli@barzilay.org> writes:
>
>> So this is at least a documentation issue,...
>
> 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.

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?]

-- 
                   ((x=>x(x))(x=>x(x)))                  Eli Barzilay:
                   http://barzilay.org/                  Maze is Life!

Re: gitconfig includes

[Jeff King]

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

> > 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.
> 
> 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?]

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

Re: gitconfig includes

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> I think it's arguable whether "--global" should behave the same.

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.

Re: gitconfig includes

[Eli Barzilay]

On Tue, Nov 29, 2016 at 4:50 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Jeff King <peff@peff.net> writes:
>
>> I think it's arguable whether "--global" should behave the same.
>
> 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.

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.

-- 
                   ((x=>x(x))(x=>x(x)))                  Eli Barzilay:
                   http://barzilay.org/                  Maze is Life!

Re: gitconfig includes

[Jeff King]

On Wed, Nov 30, 2016 at 01:54:35PM -0500, Eli Barzilay 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.

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

Re: gitconfig includes

[Eli Barzilay]

On Wed, Nov 30, 2016 at 2:06 PM, Jeff King <peff@peff.net> 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).

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.


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

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

-- 
                   ((x=>x(x))(x=>x(x)))                  Eli Barzilay:
                   http://barzilay.org/                  Maze is Life!