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.
This commit is contained in:
Joey Hess 2024-12-02 13:47:51 -04:00
parent 971d9f8057
commit 0c08ff3d2c
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
4 changed files with 43 additions and 1 deletions

View file

@ -1,3 +1,11 @@
git-annex (10.20241203) UNRELEASED; urgency=medium
* 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.
-- Joey Hess <id@joeyh.name> Mon, 02 Dec 2024 13:41:31 -0400
git-annex (10.20241202) upstream; urgency=medium
* add: Consistently treat files in a dotdir as dotfiles, even

View file

@ -48,13 +48,17 @@ hashFile hdl@(HashObjectHandle h _ _) file = do
-- So, make the filename absolute, which will work now
-- and also if git's behavior later changes.
file' <- absPath file
if newline `S.elem` file'
if newline `S.elem` file' || carriagereturn `S.elem` file
then hashFile' hdl file
else CoProcess.query h (send file') receive
where
send file' to = S8.hPutStrLn to file'
receive from = getSha "hash-object" $ S8.hGetLine from
newline = fromIntegral (ord '\n')
-- git strips carriage return from the end of a line, out of some
-- misplaced desire to support windows, so also use the newline
-- fallback for those.
carriagereturn = fromIntegral (ord '\r')
{- Runs git hash-object once per call, rather than using a running
- one, so is slower. But, is able to handle newlines in the filepath,

View file

@ -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]]

View file

@ -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.
"""]]