On Wed, Nov 30, 2016 at 01:54:35PM -0500, Eli Barzilay wrote: > I don't have any strong opinion, but FWIW, the use case I have for this > is as follows: I sync my ~/.gitconfig between my own machine and a work > machine. On the work machine though, I like people to have work emails, > and I wrote some scripts that verify that. For my case, I added an > include of a ~/.gitconfig.more which is not synced, and has values that > override the ones in ~/.gitconfig. Since I'm the one who also wrote > that script, I just added an "--includes" to the check so it won't barf > on my setup, but had it not been my script I'd be stuck. I'm not sure what your script does exactly, but in general I think the right thing for most scripts is _not_ to use a specific-file option like --global. If the script is looking up a config value on behalf of a user, it probably makes sense for it to use the normal config lookup procedure (system, global, repo, command-line), which also enables includes by default. That would make it consistent with internal git config lookups (e.g., user.name probably only ever appears in global config, but you _can_ override it at the repo level if you want to). I know that's mostly orthogonal to what we're discussing, but I'd feel more convinced that enabling "--includes" with "--global" is useful if I thought that "--global" was useful in the first place outside of a few narrow debugging cases. -Peff