mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Merge branch 'master' of ssh://git-annex.branchable.com

Browse source
This commit is contained in:
Joey Hess 2023-01-05 13:30:24 -04:00
commit cba7a2477c
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
2 changed files with 42 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

25
doc/bugs/CRLF_breaks_interoperability_Win-Ux__58__..post-receive/comment_2_e4cac0d18fd6cde1084e93d0fe997f40._comment Normal file
View file

@ -0,0 +1,25 @@
[[!comment format=mdwn
username="beryllium@5bc3c32eb8156390f96e363e4ba38976567425ec"
avatar="http://cdn.libravatar.org/avatar/62b67d68e918b381e7e9dd6a96c16137"
subject="comment 2"
date="2023-01-05T06:48:58Z"
content="""
Apologies for the delay in response.
> You can edit the hooks that git-annex installs however you need to. It will not overwrite modified hook files. If you edit this hook to have unix line endings, does the hook still work when using this repository on windows?
Thanks, that aligns with what I surmised. I didn't apply that type of workaround for the sake of the report being as linear as possible (no alterations outside of running the git-annex commands).
Yes, of course, if I run dos2unix on the hook file, the repository works for both Linux and Windows. The latter, I understand because it is using msys to run the script, which is flexible with both forms of line-endings.
> Actually, I'm having difficulty seeing how the CR could have gotten into that hook. mkHookScript uses unlines which behaves the same on Windows as on Linux, so in either case lines should be separated only by \n.
My understanding has always been... native implementations on Windows (ie. no posix emulation linkage), if you don't call open() for \"binary\", your line-feeds indicate line termination only, and then the native line ending is written to the file, ie. Windows text files. So Windows native Python, Java, etc implementations, behave this way.
If I understand correctly, git-annex is relying on a native build of GHC? And it's library behaves that way too? Is that right?
> This makes me wonder if something else modified the hook after git-annex wrote it. If so, git-annex init should complain that the hook is modified.
As per above, I doubt that there was any alterations here. I tried again with a clean scenario, and indeed, the hook files were written as described.
"""]]

17
doc/bugs/CRLF_breaks_interoperability_Win-Ux__58__..post-receive/comment_3_a3a702176a316d6b599eb2a149a293ad._comment Normal file
View file

@ -0,0 +1,17 @@
[[!comment format=mdwn
username="beryllium@5bc3c32eb8156390f96e363e4ba38976567425ec"
avatar="http://cdn.libravatar.org/avatar/62b67d68e918b381e7e9dd6a96c16137"
subject="comment 3"
date="2023-01-05T07:16:30Z"
content="""
I should add, and this is not a commentary on the implementation of git-annex, etc... but having limited experience with BSD, and understanding that it uses different line endings for text files (???)... and other considerations... the git hooks mechanism is powerful, but seemingly presents challenges for interoperability.
Maybe the right approach is actually... as I did... let the end-user find their own workaround. It seems it's not really a git-annex fault after all.
I initially thought that git-annex should write the file out correctly... but it kind of is. It's writing it out for the local sensibilities.
In this particular case, it's my challenge to solve, not the tools... if you agree, I'd be content to have this closed with no action.
But I leave it to your better judgement.
"""]]