Please describe the problem.
ref: https://github.com/datalad/datalad/issues/7173#issuecomment-1314968568
❯ mkdir "/tmp/new
dquote> line"
❯ cd "/tmp/new
line"
❯ git init
Initialized empty Git repository in /tmp/new
line/.git/
❯ git annex init
init ok
fatal: Cannot open '/tmp/new': No such file or directory
fatal: Cannot open '/tmp/new': No such file or directory
fatal: Cannot open '/tmp/new': No such file or directory
fatal: Cannot open '/tmp/new': No such file or directory
fatal: Cannot open '/tmp/new': No such file or directory
fatal: Cannot open '/tmp/new': No such file or directory
fatal: Cannot open '/tmp/new': No such file or directory
fatal: Cannot open '/tmp/new': No such file or directory
fatal: Cannot open '/tmp/new': No such file or directory
fatal: Cannot open '/tmp/new': No such file or directory
fatal: Cannot open '/tmp/new': No such file or directory
git-annex: fd:19: Data.ByteString.hGetLine: end of file
❯ git annex version
git-annex version: 10.20230214+git26-g8f2829e646-1~ndall+1
as git doesn't mind, and now annex batched commands support -z already for filenames with newlines in them, I think git-annex should tolerate repository folders with newlines in them too.
Unfortunately,
git hash-object --stdin-pathsdoes not support -z or anything like that. It is a newline based protocol.Ok, made git-annex fall back to running git hash-object once per file when the filenames contain newlines to work around that.
BTW, another problem I noticed is that the repository decription written to uuid.log contains a newline, which prevents parsing that line of the log correctly. This can also be seen by passing a value with a newline to
git-annex describe. It would also happen in the case with the newline directory if it didn't fail earlier.Also fixed this, though, with a one-way escaping, see 38e9ea8497bb2ab058e5bd46a666857789c0a84d.