pre-commit stash aborts the commit and orphans a stash when every stashed path matches HEAD (git update-index --chmod)

[marcodeltongo]

Summary

The pre-commit stash aborts the commit with

git error: No valid patches in input (allow with "--allow-empty")
Error: exited with code 1
git stash push --keep-index -m hk --include-untracked -- a.sh

Location:
    src/git.rs:84:5

whenever every path hk hands to git stash push has a worktree identical to HEAD.
The commit is not created, the staged change is wiped out of the index, and an orphaned
On <branch>: hk stash is left on the stack.

The reliable way into that state is a mode-only staged change:

git update-index --chmod=+x script.sh
git commit -m "make script executable"

--chmod moves the bit in the index only, so the file appears in git diff --name-only
(worktree vs index) and hk puts it in the stash set, while its worktree content and
mode still match HEAD byte for byte.

It is not specific to mode changes: staging an edit and then restoring the file's worktree
content to what HEAD has produces the same crash, with no chmod anywhere.

Environment

hk	1.56.1 (installed via mise)
git	2.55.0
pkl	0.32.1
OS	macOS 26.5, arm64

Reproduced on 1.53.0, 1.55.0 and 1.56.1. src/git.rs at main (27bb615) still has no guard,
so this is not a stale-version report.

Mechanism

Git::stash_unstaged builds files_to_stash from, among other sources, git diff --name-only
(worktree vs index), and push_stash then runs the pathspec form:

git stash push --keep-index -m hk --include-untracked -- <paths>

git implements the pathspec form by diffing HEAD against the worktree tree and
reverse-applying that patch:

$ GIT_TRACE=1 LC_ALL=C git stash push --keep-index -m hk --include-untracked -- a.sh
trace: run_command: git apply --index -R
error: No valid patches in input (allow with "--allow-empty")

So the criterion that puts a file into the pathspec list (index vs worktree) and the criterion
that decides whether the resulting patch is empty (HEAD vs worktree) are not the same one. A
--chmod staged mode change satisfies the first and violates the second.

Two details worth spelling out, because they shape what a fix can look like:

• --allow-empty is git apply's own flag, not git stash push's. git stash push --allow-empty
  is error: unknown option on git 2.55.0, so the suggestion in the message is not reachable from
  where hk stands and forwarding it is not an option.
• run_git_stash(&cmd)? propagates before save_stash_patch, so the $HK_STATE_DIR/patches/
  backup is never written for this failure. Those backups only exist for restore failures, and
  this one happens while creating the stash.

Damage

git creates the stash entry before the failing git apply, so after the abort:

• the commit does not happen;
• the staged change is gone from the index, so git status comes back clean;
• an orphaned On <branch>: hk stash is left behind, and hk never drops it because it returns
  Err before it records stash_commit.

The staged change is recoverable, but not where people look first: git diff HEAD stash@{0} is
empty, because the change lives in the stash's index commit:

$ git ls-tree HEAD         -- a.sh   → 100644 blob 8b2fe54  a.sh
$ git ls-tree stash@{0}    -- a.sh   → 100644 blob 8b2fe54  a.sh
$ git ls-tree stash@{0}^2  -- a.sh   → 100755 blob 8b2fe54  a.sh

On a shared stash stack (multiple worktrees off one repository) this reads as if something
reverted your work, which is how it was found.

Minimal repro

Verified verbatim against hk 1.56.1 / git 2.55.0:

#!/bin/sh
set -eu
git init -q t && cd t
git config user.email t@t.t && git config user.name t

cat >hk.pkl <<'PKL'
amends "package://github.com/jdx/hk/releases/download/v1.56.1/hk@1.56.1#/Config.pkl"

hooks {
  ["pre-commit"] {
    fix = true
    stage = true
    stash = "git"
    steps {
      ["noop"] { glob = List("**/*.sh"); check = "true" }
    }
  }
}
PKL

printf 'echo hi\n' >a.sh
git add -A && git commit -qm init
hk install

# index 100755, worktree still 100644 and byte-identical to HEAD
git update-index --chmod=+x a.sh
git commit -m "make a.sh executable"

Aftermath:

EXIT=1
status : []                             # the staged mode change is gone
stash  : [stash@{0}: On main: hk]       # orphaned
log    : fd37909 init                   # no commit

Same result with stash = "patch-file" (still an alias: StashMethod::PatchFile is declared in
src/git.rs but never matched anywhere) and with hk run pre-commit instead of git commit.
stash = "none" commits fine.

Variant matrix

All rows driven end to end through hk 1.56.1; all have git update-index --chmod=+x a.sh staged
unless noted. Pathspecs are the ones hk actually logs under HK_LOG=debug.

other state in the commit	pathspecs hk passes	git diff HEAD -- <pathspecs>	result
nothing	a.sh	empty	abort + orphan stash
staged content change in b.txt	a.sh	empty	abort + orphan stash
staged content change in a.sh	a.sh	non-empty	commits
unstaged content change in b.txt	a.sh b.txt	non-empty	commits
no --chmod; a.sh staged, then its worktree restored to HEAD content	a.sh	empty	abort + orphan stash
chmod +x a.sh on disk, not staged (index 100644, worktree 100755)	a.sh	non-empty	commits
chmod +x a.sh on disk, then git add a.sh	none (never enters the stash set)	n/a	commits

Row 2 is the one that makes this hard to work around by hand: the pathspec list is per file, so a
content change elsewhere in the same commit does not save you. It has to be in the same file, or
in another file hk also stashes.

Rows 5 and 7 together rule out the intuitive reading, that the trouble is an index mode and a
worktree mode disagreeing. Row 7 has them disagreeing (index 100644, worktree 100755) and commits
fine; row 5 has them agreeing everywhere, with no chmod in the picture at all, and aborts. The
empty-patch test predicts every row; mode divergence predicts neither of those two.

What the orphaned stash contains

Worth knowing before anyone tries to recover from it: the entry is not scoped to the pathspec.
git builds the stash commits from the whole index and worktree, and only the reset step is
restricted to <paths>. With a.sh mode-changed and an unrelated b.txt staged, the failed
git stash push ... -- a.sh leaves an entry whose first look shows only b.txt:

$ git stash show -p stash@{0}
diff --git a/b.txt b/b.txt
-content
+other content

That content is still in the index (identical blob), so the entry reads as unique work when it is
a duplicate, while the thing the index actually lost, the mode change, is only visible in the
stash's index commit:

$ git diff HEAD stash@{0}^2 --summary
 mode change 100644 => 100755 a.sh

So the abort leaves behind an entry that is misleading in both directions: it advertises content
you have not lost, and hides the change you have.

Suggested fix

Before running the pathspec git stash push, drop from the list any path whose worktree tree entry
already equals HEAD's, and skip the push entirely when nothing is left. Those are exactly the paths
that have nothing to lose in the worktree, which is why git generates an empty patch for them. A
cheap form of the same check: git diff --quiet HEAD -- <paths> and return Ok(None) when it exits 0.

One residual is worth naming rather than hiding: for a path whose worktree matches HEAD while the
index differs, skipping the stash leaves fix steps looking at HEAD content instead of staged content
for that path. For the mode-only case that is the same bytes with the old bit, and in every case it
is strictly better than destroying the staged change. Filtering per path rather than bailing out for
the whole set keeps the loss confined to the paths that would otherwise crash the hook.

[jdx]

Confirmed—your analysis of the empty HEAD-to-worktree patch and the resulting orphaned stash is correct. I opened #1283 with the aggregate git diff --quiet HEAD -- <paths> preflight you suggested, so hk returns before invoking the destructive path-limited stash when there is no patch to apply.

The PR includes end-to-end regressions for both git update-index --chmod and a staged content change whose worktree was restored to HEAD, under both libgit2 settings. Thanks for the exceptionally thorough report and recovery notes.

AI-assisted — Tool: Codex; model: openai/gpt-5; version: unavailable.