Please describe the problem.
I have created a git-annex via Windows. If I use sshfs to mount this onto a Linux server, and then setup a new remote, I encounter the error:
fatal: cannot run hooks/post-receive: No such file or directory
I've already identified that, due to the Windows created repository, the script uses crlf line-endings. And of course, the Linux kernel interprets the carriage-return as a trailing component of the shebang
#!/bin/sh^M
and obviously can't find the executable.
I've already worked around this by using a binfmt_misc approach workaround, registering the shebang with ^M to trigger a wrapper script. But I'm seeking the permanent fix of git-annex creating these hooks with unix line-endings only. I think it's fair to say, there's currently no approach that allows hooks to be in any other form than unix scripts, and I'm happy to stand corrected, that it makes little sense to have any other line-endings.
What steps will reproduce the problem?
Run git annex sync against a Windows created remote git-annex, however that is mounted, on a Linux/unix host.
What version of git-annex are you using? On what operating system?
$ git annex version
git-annex version: 8.20210223
on a Debian bullseye operating system.
Please provide any additional information below.
$ git annex sync
On branch master
Your branch is ahead of 'origin/master' by 1 commit.
(use "git push" to publish your local commits)
It took 3.28 seconds to enumerate untracked files. 'status -uno'
may speed it up, but you have to be careful not to forget to add
new files yourself (see 'git help status').
nothing to commit, working tree clean
ok
pull origin
ok
push origin
fatal: cannot run hooks/post-receive: No such file or directory
To /var/tmp/mnt/winhost-w10-5920/cygdrive/e/my.gitannex/
a0ebd1826d..15cfd91da4 git-annex -> synced/git-annex
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. I think git-annex is a hidden gem of the open source community.
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?
Actually, I'm having difficulty seeing how the CR could have gotten into that hook.
mkHookScript
usesunlines
which behaves the same on Windows as on Linux, so in either case lines should be separated only by\n
.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.Apologies for the delay in response.
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.
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?
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.
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.
Apologies, this is beryllium (by alias)... due to unforeseen circumstances, I have had to register with a different email address. I am hoping this is a temporary situation.
Further apologies... I acknowledge that I am vacillating somewhat, but I've reverted to thinking that the hooks should be generated with unix line-endings (LF).
The reason I say this is, it does appear that the pseudo-standard for files under the .git directory is that they use unix line-endings only (perhaps an actual, documented standard... I'm not sure where to look/ask to confirm it).
This is the case for files such as .git/config, and .git/refs/** etc... under Git for Windows, and even JGit running with Windows native Java.
So to me.. it seems to make sense that hook files should have unix line-endings exclusively.
There are possible other mitigations... but that's where I stand with that finally. I'm still not fussed if no actions is determined to be the best course of action.
Thanks regardless.
4e35067325022e4d8790d45557156fd1166484df fixed this. Previously, git-annex did write hook scripts with CRLF line endings.
Existing hook scripts won't be changed by git-annex, but if you delete them, and re-run
git-annex init
it will reinstall it without the CRLF.