infelicities in git hash-object --stdin-paths with special characters

[Joey Hess <id@joeyh.name>]

Apparently "Icon\r" is a common filename on OSX, anyway it's a legal
unix filename. It seems that sending a line containing that filename to
git hash-object --stdin-paths triggers some DOS-style CRLF handling.
Here I am running git version 2.45.2 on Linux.

$ touch Icon^M
$ printf 'Icon\r\n' | git hash-object --stdin-paths
fatal: could not open 'Icon' for reading: No such file or directory

$ echo 'wrong file!' > Icon
$ printf 'Icon\r\n' | git hash-object --stdin-paths
1c43b74a7787621318ee7442eb5a36e32476f326

While looking at builtin/hash-object.c to see why it might do this, I quickly
noticed another odd behavior:

$ touch '"foo"'
$ printf '"foo"\n' | git hash-object --stdin-paths
fatal: could not open 'foo' for reading: No such file or directory

$ touch '"foo'
$ printf '"foo\n' | git hash-object --stdin-paths
fatal: line is badly quoted

The documentation does not seem to mention that quoted lines in
--stdin-paths are at all special. Of course, quoting would be one way to
work around the CRLF problem, if it were documented.

It seems that some parts of git that read filenames from stdin use
strbuf_getline_lf and others use strbuf_getdelim_strip_crlf. There does
not seem to be any consistency, and my impression is any user is best
off using -z, when the command supports it, to avoid the mess.

Given all that, maybe adding -z to hash-object would be a good "fix".

-- 
see shy jo