Re: [PATCH 0/2] config includes, take 2

[Jeff King <peff@peff.net>]

On Mon, Feb 06, 2012 at 09:01:21PM -0800, David Aguilar wrote:

> I have a questions about this.  Let's say I have ~/foo1.gitconfig:
> 
> [foo]
>     bar = 1
> 
> ...and ~/.gitconfig (I forgot the syntax):
> 
> [foo]
>     bar = 0
> 
> #include "~/foo1.gitconfig"
> 
> 
> Does that mean that:
> 
>     $ git config -f ~/.gitconfig foo.bar
> 
> ...prints 0 and not 1?

Yes, though the syntax is:

  [include]
    path = foo1.gitconfig

(it doesn't respect tilde-expansion, but it probably should). Note that
the syntax was specifically selected for backwards compatibility, and to
allow manipulation with existing tools.

> I can see cases where this would be undesirable behavior.
> 
> For example, an application that uses "git config -z --list -f
> ~/.gitconfig" might expect that the result encompasses all of the
> user-specific config bits.

The problem is that an application might also expect it _not_ to happen
(e.g., if the application is really interested in knowing what's in
~/.gitconfig). Because includes aren't respected now, the safe default
seems to be not to have includes (i.e., don't change behavior for this
case).

A bigger question for me is: if you are interested in getting an answer
from anywhere, why are you restricting with "-f"? IOW, is this a
real-world problem, or a hypothetical one? And if real-world, what is
the actual use case?

> Following this to its natural conclusion means "git config" might
> learn some kind of --no-include flag for use with e.g. "git config
> --no-include -f ~/.gitconfig".  That said, I don't know where I would
> ever actually use such a flag.

It already learned it as part of my series (and --includes, as well).

> I do know where I would use an `--include` flag (if following includes
> were not the default behavior when using '-f'), though, and that's why
> I'm asking.  The problem with not having it be the default means we
> have to use a flag.  This makes it harder to support multiple versions
> of git.

Yes, that's a general problem of adding new command-line options to turn
features off or on. We could add an environment variable to control this
feature. But I'd really like to hear the compelling use case first
(i.e., both why it cannot simply be spelled "git config -z --list", and
why not following includes is not OK).

> Maybe I'm mis-interpreting what you mean by, 'do not use includes for
> "git config" in single-file mode', though.

No, I think you understand the described behavior.

-Peff