On Sat, 2018-09-08 at 13:13 -0700, Stas Bekman wrote: > I remind that the original problem came from a simple command: > > git config --local include.path '../.gitconfig' > > Which on linux removed the quotes and all was fine, and on windows > the same command kept the quotes and the user was tearing his hair > out trying to understand why the custom config was ignored. I'm quite sure that the user was not using the Git Bash shell when they entered this command, but instead using command.com or powershell or some variant of that. If you use Git Bash as your shell then quotes will be handled like any POSIX shell and the above will do what (we all) expect. If you use command.com and powershell and use single quotes, then the single quotes will be put into the config file as you observed, because those shells don't deal with single quotes. You could use double-quotes, which ARE handled by command.com and powershell; in that case they would be stripped out and would not appear in the config. If we were designing from scratch maybe using something like GNU make's "include" vs "sinclude" (silent include--this is another name for the already mentioned "-include") would work; maybe "path" and "spath" or something. But to make it work right you really want the default behavior to be "warn if the file is not found" and have the special behavior be "quiet if the file is not found" otherwise it doesn't really help beginners to avoid errors. And that's a backward- compatibility problem. To my mind, adding extra "check this" options isn't very useful either: these kinds of warnings need to be on by default to be effective. The beginners, who need them, aren't going to remember to add extra options to enable more checking. What I personally think would be more useful would be some sort of "verbose parsing" option to git config, that would parse the configuration just as a normal Git command would and show diagnostic output as the entire config is parsed: for each action line the config file name and line number, and the operation performed (and any message about it) would be printed. This could be useful in a variety of situations, for instance to discover conflicts between local, global, and system configuration, easily see where settings are coming from, etc. And as part of this output, when an include file was not present or we didn't have permissions or whatever, an appropriate error message would be generated.
