Guard post-commit hook against spurious checkpoints during interactive rebase #167
Description
Summary
During git rebase -i, git replays each selected commit and fires the post-commit hook for each one. Partio's post-commit hook will attempt to create a new checkpoint for every replayed commit — even though those commits already have checkpoints and no agent session is running.
Add a guard to the post-commit hook implementation that detects an in-progress rebase and returns early with a no-op. Detection: check for the presence of .git/rebase-merge/ or .git/rebase-apply/ directories.
Note: Partio already guards against --amend re-entry by deleting the state file before the amend. The rebase case is separate — the state file won't be present (so that guard won't trigger), but the hook still fires for each replayed commit.
Why
Without this guard, git rebase -i on a branch with many commits will attempt checkpoint creation for each replayed commit, adding unnecessary overhead and potentially creating spurious checkpoint entries if a stale state file is present.
Source
Inspired by entireio/cli PR #824 (guard session-start hook on duplicate session.created events) and the general pattern of making hooks resilient to git operations that replay commits.
Acceptance Criteria
- Post-commit hook detects in-progress interactive rebase (
.git/rebase-merge/or.git/rebase-apply/) and exits 0 immediately - Debug-level log message emitted: 'skipping checkpoint creation: interactive rebase in progress'
- Normal commits (no rebase) are unaffected
- Guard does not prevent Partio from operating on commits made after the rebase completes
- Unit test covers the rebase-detection logic with a fake git dir structure