From: Junio C Hamano <gitster@pobox.com>
Date: Fri, 27 Jan 2012 05:23:59 GMT
Subject: Re: [PATCH 1/4] config: add include directive
Message-ID: <7vk44d1zww.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20120126225140.GB12855@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

> And then because of 1a and 2a, most programs should Just Work without
> any changes, but because of 1b and 2b, any special uses will have to
> decide manually whether they would want to allow includes.
>
> Does that make sense?

In short, the "git config" interface defaults to "--no-includes" when
reading from an explicit file with "-f" and "--includes" otherwise, which
sounds like a 100% sensible default to me.

> I had a similar thought while writing it, but hoped the sentence after
> (that you snipped) would make it clear.

I think the whole paragraph makes it reasonably clear; I was merely being
pedantic to see if you or others can come up with a clear and simple way
to rephrase it that can also satisfy such pedantry.

> How about:
>
>   The included file is processed immediately, before any other
>   directives from the surrounding file.
>
> What I wanted to make clear there is the ordering, which sometimes
> matters.

Hmm, I think the original is probably easier to read.

> The one use I think is to bundle a bunch of related config options, and
> then turn them on selectively.
> ...
> but with this patch, you can do:
>
>   cat >~/.gitconfig.foo <<-\EOF
>   [foo]
>   one = 1
>   two = 2
>   EOF
>   git -c include.path=$HOME/.gitconfig.foo blah

That is quite a sensible use case actually.

Thanks.