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:
parent
971d9f8057
commit
0c08ff3d2c
4 changed files with 43 additions and 1 deletions
|
@ -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
|
||||
|
|
|
@ -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,
|
||||
|
|
|
@ -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]]
|
||||
|
|
|
@ -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.
|
||||
"""]]
|
Loading…
Add table
Add a link
Reference in a new issue