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

From: David Aguilar <davvid@gmail.com>
Date: Feb 7, 2012, 05:01 UTC
Message-ID: <CAJDDKr6A2UvB3D-Dapw7WCEzWfzLoLd0E8MSDjT0RtdxFeWZAQ@mail.gmail.com>
In-Reply-To: <20120206062713.GA9699@sigill.intra.peff.net>

On Sun, Feb 5, 2012 at 10:27 PM, Jeff King <peff@peff.net> wrote:

Show 12 quoted lines

> That leaves the file-inclusion bits:
>
>  [1/2]: imap-send: remove dead code
>  [2/2]: config: add include directive
>
> The first patch is new in this round, and is a necessary cleanup for the
> second patch (though it might be worth applying regardless).
>
> The second patch corresponds to patch 1/4 from the previous round. Among
> the functional changes are:
>
>  1. do not use includes for "git config" in single-file mode

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?

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.

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.

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.

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