On Sat, Sep 08 2018, Stas Bekman wrote: > On 2018-09-08 12:30 PM, Martin Ågren wrote: >> Hi Stas >> >> On Sat, 8 Sep 2018 at 21:00, Stas Bekman <stas@xxxxxxxxxx> wrote: >>> [include] >>> path = '../.gitconfig' > >> Actually, there is a test explicitly testing that 'missing include files >> are ignored'. I couldn't find a motivation for this in 9b25a0b52e >> (config: add include directive, 2012-02-06). > > And also to stress out, that the file is not missing. At least in the > world of unix, in particular its many shells, - command line arguments > "xyz", 'xyz', xyz are often deemed to be the same if there are no spaces > in the word. So that's why it took us a lot of trial and error to even > consider the quotes in '../.gitconfig' as a problem. While git deems it > different, to me: > > path = '../.gitconfig' > path = "../.gitconfig" > path = ../.gitconfig > > appear to be the "same". So git needs to have a way to say otherwise. > > I realize I am going back to the issue of quoting here, after suggesting > to ignore it. So to clarify I'm bringing it up only in the context of > wanting git to tell the user what it wants, and not necessarily asking > to support all the possible ways one could quote a filepath. 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.
