Jeff King <peff@xxxxxxxx> 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. -- 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