Re: [PATCH 1/4] config: add include directive
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jan 27, 2012, 05:23 UTC
- Message-ID
- <7vk44d1zww.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <20120126225140.GB12855@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 5 quoted lines
> 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.
Show 7 quoted lines
> 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.
Show 11 quoted lines
> 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.