28 lines
1.4 KiB
Text
28 lines
1.4 KiB
Text
|
On Windows, isExecutable fails to detect a file that is indeed executable
|
||
|
as such. This prevents git-annex from running the pre-commit-hook
|
||
|
on Windows.
|
||
|
|
||
|
getFileStatus yields a fileMode of 100666, which is
|
||
|
clearly a dummy mode. Not surprising, since unix-compat is partial stubs
|
||
|
on windows.
|
||
|
|
||
|
Actually, isExecutable is ok (it needs to check unix modes because it is
|
||
|
used on file modes coming out of git). But, getFileStatus is the wrong
|
||
|
thing to be using on Windows to check if a hook exists and is executable.
|
||
|
|
||
|
I don't see anything in Win32 or Win32-extras on hackage that can check
|
||
|
executablility. Looking at git's source, it uses `access(path, X_OK) < 0`;
|
||
|
haskell equivilant is System.Posix.Files.fileAccess, but the version
|
||
|
in unix-compat has the same problem as checking getFileStatus's fileMode.
|
||
|
|
||
|
I think it's reasonable to assume that if a hook exists on windows, it's
|
||
|
intended to be executable, and try to run it. Actually, testing with
|
||
|
msysgit, it runs hooks whether or not they have the execute bit set!
|
||
|
So, done that now.
|
||
|
|
||
|
However, now git-annex tries to run the hook but fails when it's a shell
|
||
|
script because #!/bin/sh is useless on windows. It looks to me like msysgit
|
||
|
runs "sh hook" to work around that, and it is in fact parsing the shebang
|
||
|
line and dispatching the interpreter. Ugh. (Also, pre-commit.bat doesn't
|
||
|
get run.) Ok, added this same hack to git-annex. [[done]] --[[Joey]]
|