husky: hook was ignored because it's not set as executable

I had that problem in WSL after init on Windows 11. This is a scenario similar to the issue you raised.

I also posted an answer on stackoverflow, but I was able to solve it with the command below. If you commit after reflecting once, the problem does not occur continuously.

chmod ug+x .husky/*

I think it’s probably a problem that wasn’t created taking into account the file permissions of Linux at the time of init on Windows.

chmod works, but it is not normal solution. It is trick. We all work under different OSs and tool should work correctly under each of them and tool setup should be portable among them by simple commit/checkout. The only acceptable one is some sort of automatic post-tune that automatically finds the error and fixes it (and maybe requests to commit changes).

chmod ug+x .husky/*

It solved my problem

After doing some research, this seems to be because Windows does not keep track of the executable bit of a file.

When a git commit hook created by husky on a Windows computer is run on a Linux computer, it does not work due to differences in file permission handling between the two systems. In particular, Windows does not keep track of the executable bit of a file, whereas Unix-based systems rely on this information to determine whether a file can be executed as a program.

Although Git on Windows does keep track of the executable bit, it is not being set properly on Windows systems. After committing (or staging) a new husky hook file you can see that the file is missing the executable bit

$ npx husky add .husky/pre-commit "echo test"
$ git stage .\.husky\test
$ git ls-files --stage .\.husky\pre-commit
100644 36af219892fda8ea669cd4b6725cd7b892231967 0       .husky/pre-commit

644 is equivalent to -rw-r--r--

For the commit hook file to work on Unix systems, we need the file to have a permission mode of 755 (equivalent to -rwxr-xr-x).

When husky creates a new commit hook file, it actually sets the permission mode to 755

https://github.com/typicode/husky/blob/3c0e08d3ca4d01d04ebb92089e68c47e131ab6be/src/index.ts#LL70-L78C4

But, since Windows does not keep track of the executable bit, the executable bit gets lost, it is not written to the git repo, and the commit hook files will be missing the bit when the repo is cloned onto a Unix system.

The fix for existing projects is to set the file using the git update-index command. The previous commit hook file would be fixed as follows:

$ git ls-files --stage .\.husky\pre-commit
100644 36af219892fda8ea669cd4b6725cd7b892231967 0       .husky/pre-commit
$ git update-index --chmod=+x .\.husky\pre-commit
$ git ls-files --stage .\.husky\pre-commit       
100755 36af219892fda8ea669cd4b6725cd7b892231967 0       .husky/pre-commit

For those wondering if project will be cloned and run as expected, add this second step to husky install script :

{
...
"prepare": "husky install | chmod ug+x .husky/*"
}

chmod ug+x .husky/*

^ this really can fixed but only for one time, “hook was ignored because it’s not set as executable” error appears again once I run commit on second time.

---

update: i able to solve it by git update-index --chmod=+x .husky/pre-commit

After doing chmod chmod ug+x .husky/* I’m getting (after committing) env: sh\r: No such file or directory

chmod u+x .husky/* with no g was enough for me, see https://askubuntu.com/q/518259/792595.

@parkgang had same issue on macbook

chmod ug+x .husky/*

fixed my problem

The issue persists on macOS 13.2, VSCode 1.75.1, husky ^8.0.1.

chmod ug+x .husky/*

^ this really can fixed but only for one time, “hook was ignored because it’s not set as executable” error appears again once I run commit on second time.

update: i able to solve it by git update-index --chmod=+x .husky/pre-commit

git update-index --chmod=+x .husky/pre-commit it doesn’t work for me. You mean if I try this only once, I don’t have to do chmod ug+x .husky/* every time?

@d-belic @40x To resolve env: sh\r: No such file or directory issue:

Sometimes when files are transferred between different operating systems, the line endings can get converted to the wrong format, which can cause issues with shell scripts. Running dos2unix on the affected files is a quick and easy way to fix the line ending format and ensure that shell scripts can be executed without errors.

In my case, it was a transfer from Windows to MacOS.

This helped me:

1. Install brew install dos2unix
2. Convert all .sh files in repo: find . -type f -name '*.sh' -exec dos2unix {} \;
3. Conver all your hooks. I have one hook so I run only one command: dos2unix .husky/pre-commit

Hope it’ll help you.

Hello!

I had the same issue since last week, on Windows with WSL2, on projects with many collaborators… I tried several things, but the only one is worked for me, is using chmod ug+x .husky/* on main branch. Git get the mode change and update it. It’s working with all others branchs, for everyone.

 .husky/commit-msg | 0
 .husky/pre-commit | 0
 .husky/pre-push   | 0
 3 files changed, 0 insertions(+), 0 deletions(-)
 mode change 100644 => 100755 .husky/commit-msg
 mode change 100644 => 100755 .husky/pre-commit
 mode change 100644 => 100755 .husky/pre-push

After doing chmod chmod ug+x .husky/* I’m getting (after committing) env: sh\r: No such file or directory

@d-belic did you fix this issue?

same for me. but i tried to install the husky to my Mac machine, it works fine on both Mac and Windows

same for me. i initiated the setup in windows, but when moved to mac. the setup was not executable by default. this is really annoying since we are in the team each has different operating system.

https://stackoverflow.com/questions/8598639/why-is-my-git-pre-commit-hook-not-executable-by-default hope to help for you. @yury-tk

also for author. copy the git hook sample and change file. not create hook file