The topic nd/conditional-config-include hit a problem on Windows [1].
The test basically does this (much simplified)
echo '[include]path=foo' >~/.gitconfig
cd ~ && git init foo
At some point in 'git init' after 'foo' directory has been created, we
request to include ~/foo as an extra config file. But it's a directory
and we get some error like this
fatal: bad config line 2 in file ~/.gitconfig
The message gives no clue that 'foo' is a directory (and probably
wasted a good chunk of time of Johannes). This series tells the user
about that.
The other half of the problem is, the same test runs without error on
Linux because it looks like fopen(dir) returns NULL on Windows, but
non-NULL on Linux and only subsequent read() returns EISDIR.
Unfortunately the config parser conflates errors with eof, I think.
And it simply sees <dir> as an empty config file, ie. a valid config
file. So no "bad config line..."
I'm making sure even Linux now reports loud and clear that config
files should be _files_. The same treatment is done for .gitattributes.
I'm not so sure about .gitignore because it uses open(), not fopen()
and I don't know if open() behaves differently on Windows.
I briefly considered fopen() and open() wrappers that always rejects
directories (if you need to open a directory, do it without wrappers),
but discarded it because it adds an extra stat() call everywhere.
[1]
https://github.com/git/git/commit/484f78e46d00c6d35f20058671a8c76bb924fb33#commitcomment-21121210
Nguyễn Thái Ngọc Duy (2):
config: check if config path is a file before parsing it
attr.c: check if .gitattributes is a file before parsing it
abspath.c | 7 +++++++
attr.c | 8 +++++++-
cache.h | 1 +
config.c | 9 +++++++++
t/t1300-repo-config.sh | 5 +++++
5 files changed, 29 insertions(+), 1 deletion(-)
--
2.11.0.157.gd943d85
