deal with git's CFLR nonsense once again

Work around git hash-object --stdin-paths's odd stripping of carriage
return from the end of the line (some windows infection), avoiding crashing
when the repo contains a filename ending in a carriage return.

doc/bugs/hFlush__58___resource_vanished___40__Broken_pipe__41__.mdwn

@@ -73,3 +73,5 @@ It succeeds at moving the large `test2` file into `.git/annex/objects` and symli
 ### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
 
 Yes! :) It's helped me manage an unruly mess of files, backups, and backups of backups.
+
+> [[fixed|done]] --[[Joey]]

doc/bugs/hFlush__58___resource_vanished___40__Broken_pipe__41__/comment_1_0a3132101d9cc48afa55d467d1c3e12a._comment

@@ -0,0 +1,28 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2024-12-02T16:41:07Z"
+ content="""
+Reproduced on linux. This is pretty surprising since `\r` is not a
+particularly special character.
+
+Adding any file not matching largefiles with '\r` in its name will trigger
+it, the rest is not needed.
+
+`git hash-object --stdin-paths` is what is failing.
+
+	printf '/home/joey/tmp/tr/example/Icon3\r\n' | git hash-object --stdin-paths
+	fatal: could not open '/home/joey/tmp/tr/example/Icon3' for reading: No such file or directory
+
+So, this is a misbehavior in git, which prevents passing a filename ending
+in '\r' into --stdin-paths here. Probably git is removing DOS style CRLF
+when it should not. I have reported this (and several related bugs) to the
+git mailing list so it might get fixed.
+
+`git cat-file --batch` also has this behavior, and git-annex already works
+around it by treating "\r" the same as "\n" and avoiding using the batch
+interface for it. (It could use -z, which avoids the problem, but older
+git's don't support that option.)
+
+I've made git-annex treat "\r" as special for git hash-object as well.
+"""]]