On Sun, Feb 5, 2012 at 10:27 PM, Jeff King <peff@xxxxxxxx> wrote:
> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html