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

From: Jeff King <peff@peff.net>
Date: Feb 7, 2012, 05:17 UTC
Message-ID: <20120207051719.GA11598@sigill.intra.peff.net>
In-Reply-To: <CAJDDKr6A2UvB3D-Dapw7WCEzWfzLoLd0E8MSDjT0RtdxFeWZAQ@mail.gmail.com>

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

Show 18 quoted lines

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

Show 5 quoted lines

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

Show 5 quoted lines

> 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