fix(hooks): guard GRAPHIFY_BIN assignment against sh -e exit when graphify not in PATH

[j-strum]

Problem

Husky v9's h runner invokes hooks with sh -e. On macOS (and any POSIX sh), a failing command substitution in a variable assignment — VAR=$(cmd_that_returns_1) — propagates the non-zero exit code, and sh -e terminates the script immediately.

When graphify is installed via pyenv (shim at ~/.pyenv/shims/graphify) and a GUI git client like SourceTree runs git with a stripped PATH that excludes ~/.pyenv/shims, command -v graphify returns exit code 1. The entire hook exits with code 1 before reaching the graceful exit 0 fallback — causing Husky to report:

husky - post-checkout script failed (code 1)
husky - post-commit script failed (code 1)

Reproducible with:

sh -e -c 'VAR=$(command -v does_not_exist 2>/dev/null); echo "survived"'
# exits 1, "survived" never prints

The same issue affects any tool that strips user PATH entries: SourceTree, Tower, VS Code's built-in git, cron, and CI runners.

Fix

|| true absorbs the non-zero exit so the assignment always succeeds. GRAPHIFY_BIN is left empty, and the existing if [ -n "$GRAPHIFY_BIN" ] guard + python3 fallback + final exit 0 handle the "not found" case correctly as intended.

-GRAPHIFY_BIN=$(command -v graphify 2>/dev/null)
+GRAPHIFY_BIN=$(command -v graphify 2>/dev/null) || true

Change

One line in graphify/hooks.py — the _PYTHON_DETECT shell template string shared by both the post-commit and post-checkout hook generators.

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Improves the robustness of the embedded shell snippet used to detect the graphify executable so the hook logic doesn’t fail when graphify isn’t on PATH.

Changes:

• Make command -v graphify non-fatal by appending || true to the assignment line.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.