[teddytennant]

Closes #1471

Context

With stage_fixed: true, guard.withHiddenUnstagedChanges calls git.AddFiles to stage the files a job has fixed. When that git add fails, the error is only logged:

if err := g.git.AddFiles(g.filesToStage.Files()); err != nil {
    g.logger.Warn("Couldn't stage fixed files:", err)
}

return resErr

resErr is the wrapped result of the jobs, so the staging failure never reaches the caller. Lefthook.run sees err == nil, prints a green summary and exits 0 — the commit is created with the pre-fix content while nothing in the exit status tells the wrapper or CI that the formatter gate did not actually do its job.

Reproducer from the issue: run the hook without GIT_INDEX_FILE during git commit -a, so the staging git add collides with the index.lock git holds:

> git add --force -- src/example.tsx
fatal: Unable to create '.../.git/index.lock': File exists.
Couldn't stage fixed files: error in batch 0: exit status 128
summary: (done in 2.75 seconds)
✔️ lint-staged (2.75 seconds)

Changes

errors.Join the AddFiles error into the returned error at both call sites — the len(partiallyStagedFiles) == 0 early return and the CanRestoreUnstagedChanges() branch. The warning is kept as is, so the immediate output does not change; only the returned error does. Lefthook.run then reports failed to run the hook: ... and exits non-zero.

AddFiles returns nil for an empty file list, so hooks that stage nothing are unaffected — the join only happens on a real error.

Added Test_guard_wrap_stageFixed to guard_test.go covering both call sites, plus the two non-failing paths (nothing to stage, and a successful git add) so the change cannot start failing hooks that used to pass. cmdtest.Out grew an Err field so the ordered command double can simulate a failing git call; it is a new field with a nil zero value, existing expectations behave exactly as before.

Verification

Before the fix (test only, guard.go reverted):

--- FAIL: Test_guard_wrap_stageFixed (0.00s)
    --- FAIL: Test_guard_wrap_stageFixed/staging_fixed_files_fails (0.00s)
        	Error:      	Expected error with "exit status 128" in chain but got nil.
    --- FAIL: Test_guard_wrap_stageFixed/staging_fixed_files_fails_with_partially_staged (0.00s)
        	Error:      	Expected error with "exit status 128" in chain but got nil.
    --- PASS: Test_guard_wrap_stageFixed/no_files_to_stage (0.00s)
    --- PASS: Test_guard_wrap_stageFixed/fixed_files_staged (0.00s)

After:

--- PASS: Test_guard_wrap_stageFixed (0.00s)
    --- PASS: Test_guard_wrap_stageFixed/no_files_to_stage (0.00s)
    --- PASS: Test_guard_wrap_stageFixed/fixed_files_staged (0.00s)
    --- PASS: Test_guard_wrap_stageFixed/staging_fixed_files_fails (0.00s)
    --- PASS: Test_guard_wrap_stageFixed/staging_fixed_files_fails_with_partially_staged (0.00s)

make test and make lint (golangci-lint 2.11.4, 0 issues) pass. make test-integration passes 57/57; tests/integration/run_interrupt.txt is flaky on my machine but fails the same way on an unmodified master, so it is unrelated.

Not changed

• No new config option. The issue offered "fail the hook, or make it configurable"; failing looks like the right default since the alternative is silently committing unfixed content, and stage_fixed already fails the hook for every other error in this path. Happy to put it behind a flag instead if you prefer to keep the old behaviour available.
• The else branch (CanRestoreUnstagedChanges() false) is untouched: it already overwrites wrappedErr with errRestorationConflict, so those runs fail regardless.
• No integration test — making git add fail deterministically inside testscript needs an index lock dance that would be more fragile than what it verifies.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

_{Reviews (2): Last reviewed commit: "fix: add context to the staging error" | Re-trigger Greptile}

[teddytennant]

Anything I can do to help get this reviewed?

[mrexox]

Hey @teddytennant! Sorry for a long delay. I'm going to merge the changes, thank you for preparing the PR!

[aminya]

I was on 2.1.10, and I noticed the changes suddenly got disappeared from history altogether when the hook failed and had to use reflog for an emergency restore. Does this PR address that issue potentially? @teddytennant

[teddytennant]

No. This is not in 2.1.10, and a failing hook does not move HEAD. The only reflog entry lefthook writes is the lefthook auto backup stash, and this PR does not touch that.