pre-push broken: git passes pre-push args twice, steps silently skipped as "no file matches"

[sherifabdlnaby]

Note

🧍🏻 Human Note

Hey! The below was drafted by Fable Claude to help describe the Bug. I did face this bug, and verified the findings myself.

Summary

On Git 2.54+, where hk install writes config-based hooks, git passes the pre-push arguments (remote name and URL) twice. hk parses the first pair as [REMOTE] [URL] and the duplicate pair as [FILES]..., and an explicit file list overrides push-range file resolution. Since origin and a URL never match any step's glob, every pre-push step is skipped with no file matches for step and hk exits 0.

Warning

Push gates on config-based installs never block anything. Every push passes, and there is no error or warning to notice. pre-commit is unaffected (git passes it no args). commit-msg gets the message-file path duplicated into [FILES]..., harmless today but wrong for the same reason.

Verified on hk 1.50.0 (latest) and 1.48.0, git 2.55.0, macOS, hooks installed via hk install --mise. The 1.49.0 and 1.50.0 changelogs don't touch pre-push argument handling.

Repro

hk.pkl with a pre-push step that should always fail:

hooks {
  ["pre-push"] {
    steps {
      ["block-everything"] {
        glob = List("src/**")
        check = "false"
      }
    }
  }
}

1. On git >= 2.54, run hk install --mise
2. Commit a change under src/
3. git push

The push should be blocked. It succeeds instead, and the step never runs.

Root cause

The installed command is:

hook.hk-pre-push.command=test "${HK:-1}" = "0" || mise x -- hk run pre-push --from-hook "$@"

Git's config-hook runner already appends the hook arguments to the command. With the literal "$@" also present, hk's argv ends up as:

hk run pre-push --from-hook origin <url> origin <url>
                            [REMOTE][URL] [FILES]...

The stdin refs parse fine; the args just land in [FILES]... a second time. The same behavior reproduces without git at all by doubling the args on a manual invocation, and passing them once parses correctly (REMOTE and URL filled, FILES empty, steps run against the push range).

Debug log: git-invoked hook on hk 1.50.0 (bypass)

HK_LOG=debug git hook run --to-stdin=<refs-file> pre-push -- origin https://github.com/sherifabdlnaby/skills.git

  files - Fetching git status (2 files)
✔ files - Fetching git status (2 files)
DEBUG files: {"https://github.com/sherifabdlnaby/skills.git", "origin"}
DEBUG version-bump: no file matches for step
DEBUG pre-push: hook finished successfully
exit: 0

The "2 files" are the remote name and the URL. git push itself behaves the same; git hook run is just easier to capture.

Debug log: same refs and args passed once on hk 1.50.0 (works)

$ printf 'refs/heads/main <local sha> refs/heads/main <remote sha>\n' | \
    HK_LOG=debug hk run pre-push --from-hook origin https://github.com/sherifabdlnaby/skills.git

  files - Fetching files between d1bdb461fb9f... and f69072bf72d2... (23 files)
DEBUG files: {".claude-plugin/plugin.json", ".cursor-plugin/plugin.json", "README.md", "skills/afk/README.md", ...}
  version-bump – 11 files – skills/** hooks/** .claude-plugin/* .cursor-plugin/* – mise run version:check
✔ version-bump

Minimal repro without git: doubled args

$ printf 'refs/heads/main <local sha> refs/heads/main <remote sha>\n' | \
    HK_LOG=debug hk run pre-push --from-hook origin <url> origin <url>

  files - Fetching git status (2 files)
DEBUG files: {"<url>", "origin"}
DEBUG version-bump: no file matches for step

Identical input with origin <url> passed once runs the steps against the refs.

Seen in the wild

sherifabdlnaby/skills guards pushes with a version-bump push gate that fails when plugin content changes without a manifest version bump. Two pushes shipped skills/** changes with the version untouched and went straight through: 70b69b7 and 241b803. Running the gate's task by hand against the same range fails as designed; only the hook path lets it through.

Suggested fix

Omit "$@" from the command hk install writes for config-based hooks, since git appends the arguments itself. The legacy script shims still need it.

Workaround

Rewrite the installed commands without "$@":

git config --local hook.hk-pre-push.command 'test "${HK:-1}" = "0" || mise x -- hk run pre-push --from-hook'
git config --local hook.hk-commit-msg.command 'test "${HK:-1}" = "0" || mise x -- hk run commit-msg --from-hook'

This gets reverted the next time hk install runs (confirmed: the 1.50.0 postinstall rewrote both commands with "$@" again). Installing with hk install --legacy avoids the problem entirely.

---

_{🤝 Human Guided: Posted by Claude on behalf of @sherifabdlnaby.}

[jdx]

Thanks for the detailed report. I confirmed the config-based hook runner already forwards hook arguments, so the explicit "$@" in hk duplicated them and caused the pushed range to be replaced by the remote name and URL.

The fix is ready for review in #1065. It removes the redundant forwarding from config-based hooks, preserves it for legacy shims, and adds an end-to-end config-based pre-push regression test.

This comment was generated by Codex.