On Sat, Sep 08 2018, Stas Bekman wrote:
> 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
> 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.
>
> 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
> config file.
>
> 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
> supporting users.
>
> I hope this clarifies the situation.
Yeah, some version of this is sensible. There's at least a doc patch in
here somewhere, if not some "warn if missing" mode.
So don't take any of this as minimizing that aspect of your bug report.
*But*
There's just no way that "git" the tool can somehow in a sane way rescue
you from knowing the quoting rules of the shell on your system, which
differ wildly between the likes of Windows and Linux.
We guarantee that if you pass us the string "foo" it'll work the same
(for the purposes of config syntax, and most other things on all
systems).
We can't guarantee that just because on one system/shell "foo" means the
same as 'foo' when you type it into the terminal, but others it doesn't
that we'll treat it the same way, it's ultimately up to you to know the
quoting rules of your system shell.
On linux/bash I can also do "git config foo.bar <(some-command)", and
there's some systems where that'll be passed in as though (on
linux/bash) we'd passed in:
git config foo.bar "<(some-command)"
What are we supposed to do with that? In particular in the case where
"foo.bar" is supposed to point to a valid filename, and
"<(some-command)" *is* a valid filename?
