bert.hausmans
37af961b3e
Lefthook v2 runs `git lfs pre-push` internally for pre-push hooks (per docs/usage/features/git-lfs.md; confirmed in internal/run/controller/ lfs.go where the internal handler invokes `git lfs pre-push <remote> <url>` with a buffered `cachedStdin`). Our manual `git-lfs:` command in lefthook.yml was a second invocation against the same remote; the duplicate is directly visible in `LEFTHOOK_VERBOSE=1` output as `[git-lfs] executing hook` (internal) followed by `[lefthook] run: git lfs pre-push` (manual). The previous fix attempt (piped: true, commit1b06804) was based on a wrong understanding of `piped`'s semantics — `piped` controls fail-fast behavior, not stdin routing or sequencing. Default lefthook behavior is already sequential per docs/configuration/parallel.md. That "fix" was placebo; incident 2 (F2 push, zero LFS objects, commit99eedb6) proved it. Phase A investigation: documentary + source confirmation that lefthook owns the LFS pre-push call. Phase B sandbox test against a filesystem remote confirmed the duplicate execution in logs but did NOT reproduce the production hang — likely because the duplicate manual call against a local remote has no LFS server to interact with. A network-y remote (Gitea over SSH/HTTPS) appears to be part of the trigger. Two mechanisms remain plausible (H1: PTY-stdin without EOF in `while read` loop per docs/configuration/use_stdin.md; H4: server-side LFS interaction on the duplicate call). Both are eliminated by the same fix: remove the manual command. LFS uploads continue to work via lefthook's internal handler (verified in sandbox post-fix). Regression coverage: scripts/test-lefthook-pre-push.sh asserts exactly one internal LFS invocation, zero manual ones, and `Uploading LFS objects: 100%` present, against a disposable sandbox. See dev-docs/ADR-LEFTHOOK-LFS-INTEGRATION.md for full context, both misconceptions to prevent regression, and the alternative-scenarios playbook if Phase E ever regresses. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
37 lines
1.6 KiB
YAML
37 lines
1.6 KiB
YAML
# Lefthook configuration.
|
|
#
|
|
# Replaces the hand-rolled scripts that previously lived under
|
|
# .githooks/ and were registered via `git config core.hooksPath
|
|
# .githooks`. Behaviour is intentionally 1:1 with those scripts —
|
|
# see WS-3 session 1a notes for the migration record.
|
|
#
|
|
# The .githooks/ scripts remain on disk and contain the actual logic
|
|
# (gating against .claude-sync.conf, merge-commit handling, the
|
|
# non-blocking pre-push warning). lefthook dispatches to them so the
|
|
# delicate gating logic isn't re-translated into YAML. See
|
|
# .githooks/README.md for details.
|
|
|
|
post-commit:
|
|
commands:
|
|
sync-claude-docs:
|
|
run: bash .githooks/post-commit
|
|
|
|
pre-push:
|
|
# LFS is handled by lefthook's built-in pre-push LFS hook (see
|
|
# docs/usage/features/git-lfs.md). Do NOT add a manual `git lfs
|
|
# pre-push` command here — it duplicates the internal call and
|
|
# historically caused the pre-push to hang. Background and
|
|
# mechanism: dev-docs/ADR-LEFTHOOK-LFS-INTEGRATION.md.
|
|
commands:
|
|
sync-check:
|
|
run: bash .githooks/pre-push
|
|
# Manual smoke tests need `lefthook run pre-push --force`:
|
|
# without `--force`, lefthook v2 inspects {push_files} (the
|
|
# diff between local and remote) and skips when that list is
|
|
# empty, which is always the case during a manual run. On a
|
|
# real `git push` with commits the file list is non-empty and
|
|
# the command fires — matching the legacy hook's "always runs"
|
|
# behaviour. (Pushing with zero new commits would be skipped
|
|
# under lefthook but is a no-op for the sync-staleness warning
|
|
# anyway, so behaviour stays effectively 1:1.)
|