Re: git silently ignores include directive with single quotes
- Date: Sat, 8 Sep 2018 13:13:00 -0700
- From: Stas Bekman <stas@xxxxxxxxxx>
- Subject: Re: git silently ignores include directive with single quotes
On 2018-09-08 01:02 PM, Ævar Arnfjörð Bjarmason wrote:
> Aside from other issues here, in the "wold of unix" (not that we only
> use the git config syntax on those sort of systems) you can't assume
> that just because some quoting construct works in the shell, that it
> works the same way in some random config format. If you look in your
> /etc/ you'll find plenty of config formats where you can't use single,
> double and no quotes interchangeably, so I don't see what hte confusion
> is with that particular aspect of this.
> Although as I mentioned in <87bm97rcih.fsf@xxxxxxxxxxxxxxxxxxx> the fact
> that we ignore missing includes definitely needs to be documented, but
> that our quoting constructs in our config format behave like they do in
> POSIX shells I see as a non-issue.
I agree that I should make no such assumptions. Thank you. But it is a
cross-platform problem. I remind that the original problem came from a
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.
So you can say, don't use the quotes in first place. But what if you have:
git config --local include.path 'somewhere on the system/.gitconfig'
you have to use single or double quotes inside the shell to keep it as a
single argument, yet on some windows set ups it'll result in git
ignoring this configuration directive, as the quotes will end up in git
I'd say at the very least 'git config' could have an option
--verify-path or something similar and for it to validate that the path
is there exactly as it adds it to .git/config at the time of running
this command to help the user debug the situation. Of course this won't
help if .git/config is modified manually. But it's a step towards
I hope this clarifies the situation.
Stas Bekman <'))))>< <'))))><