dotnet format (without --verify-no-changes) rewrites files on disk. Because git stash push --keep-index leaves the staged content in the working tree, the format command modifies those staged files. The hook then detects the diff, aborts the commit, and the trap pops the stash — but the formatter's modifications to the working tree are NOT reverted. The developer's working copy now contains formatter changes they never asked for, mixed with their original edits, and on the next git add -u/commit they will commit formatter output silently. The PR description claims the hook uses --verify-no-changes (check-only), but the actual script does not.

Also found at:

• .githooks/pre-commit:25-26

git stash push --keep-index creates no stash entry when there are no unstaged changes (and exits 0 due to || true). The later git stash list | grep -q "$STASH_NAME" correctly skips popping in that case, but the pattern match is a substring search against git stash list output, which could be matched by an unrelated user stash whose message happens to contain pre-commit-<timestamp> (unlikely but possible). More importantly, on a stash-conflict pop failure, the script tells the user to run git stash pop, but does not identify which stash to pop — the user may have multiple stashes and pop the wrong one.

The setup script configures core.hooksPath but does not ensure that .githooks/pre-commit is executable. If the file is checked out without the executable bit (e.g., on systems where git's filemode is not preserved or the file was added without +x), the pre-commit hook will silently fail to run, defeating the purpose of the hook. Adding chmod +x .githooks/pre-commit in the setup script guarantees the hook runs as intended.