From 73c02e4fe36a3e0ed584e4f9a603649445382e59 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Thu, 26 Oct 2023 15:22:22 -0400 Subject: [PATCH] comment --- ..._72e4c3a200e3fceb2afd4df563eaa5d4._comment | 31 +++++++++++++++++++ 1 file changed, 31 insertions(+) create mode 100644 doc/forum/Windows_eol_issues/comment_1_72e4c3a200e3fceb2afd4df563eaa5d4._comment diff --git a/doc/forum/Windows_eol_issues/comment_1_72e4c3a200e3fceb2afd4df563eaa5d4._comment b/doc/forum/Windows_eol_issues/comment_1_72e4c3a200e3fceb2afd4df563eaa5d4._comment new file mode 100644 index 0000000000..39531ff1b5 --- /dev/null +++ b/doc/forum/Windows_eol_issues/comment_1_72e4c3a200e3fceb2afd4df563eaa5d4._comment @@ -0,0 +1,31 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 1""" + date="2023-10-26T18:36:59Z" + content=""" +The .git/annex/mergedrefs problem seems to indicate that `git show-ref` is +outputting lines ending with CRLF. That's surprising to me, I thought git +commands on Windows didn't output CRLF at least when piped. +Can you show the output of that command fed through `cat -vet` please? + +In retrospect it would be better if annex pointer files did not end in a +newline at all. It's not really necessary that they do, and that would +avoid git for windows from messing with their content when merging them +from elsewhere. However, AFAIK git-annex manages to not break despite git +doing that to its pointer file, by ignoring CR in pointer files +(see [[!commit 4d89a1ffd1b4bfd423c11c9e703e9d2fb0f5fb25]]). +So I'm not sure what problem you're demonstrating with that example merge? + +git-annex list is displaying CRLF for the header because it uses putStrLn +for it, and putStrLn on Windows uses CRLF by default (due to the default NewlineMode +on Windows). Then for the file list it uses ByteString.Char8.putStrLn, which does +not use CRLF. Since those two are generally seen as equivilant and code is +often switched between them to improve performance, it would be a real +ongoing pain point to remember this gotcha. This makes me think that +git-annex on windows ought to `hSetNewlineMode stdout noNewlineTranslation` +so it consistently outputs without CRLF. + +About the CRLF in the hooks, I know it's been discussed somewhere before, +but I can't remember where. IIRC there were some complexities involving +what the bash bundled with git expected to find. +"""]]