Repository navigation
laptop-autocommit: no merge/cherry-pick-in-progress guard — the every-minute sweep finalizes a live merge as an 'autocommit:' commit and pushes it #1807
Description
laptop-autocommit: no merge/cherry-pick-in-progress guard — the every-minute sweep finalizes a live merge (or cherry-pick) as an "autocommit:" commit and pushes it
Evidence
nixos/home/laptop-autocommit.sh (29 lines, sha256 e58fea91… on main e91098f1) is run every minute per repo by the timers in nixos/home/laptop-autocommit.nix (OnCalendar = "*-*-* *:*:00", repos: ~/.openclaw, ~/hatch, ~/hatch-personal).
Its only in-progress guard is the index lock:
:11—[ -e "$d/.git/index.lock" ] && exit 0— the only busy check.:14-15— it then requires only that the current branch is the default branch. During a merge or cherry-pick onmain, the branch ismain.:16-22—git add -u, and if the index differs, a baregit commit -q -m "autocommit: …".:24-28— the result is then pushed toorigin <default-branch>.
There is no check for MERGE_HEAD, CHERRY_PICK_HEAD, REVERT_HEAD, rebase-merge/rebase-apply, or .git/sequencer anywhere in the script. The sibling keeper script learned exactly this lesson in #1771 and now guards on all of them (nixos/home/laptop-repo-keeper.sh:65, using the absolute git dir since a worktree's .git is a file). The autocommit script, added the same day (#1723), never got the guard.
Probe (laptop, verbatim script from the laptop primary clone, sha-identical to main)
Probe dir: ~/git/fleet/probe-2026-10-28-laneB-autocommit/ (throwaway repos with a local bare origin):
- Control — ordinary tracked change on
main, no operation in progress: committed asautocommit: …and pushed. PASS (intended behaviour). - Merge in progress — conflicting merge of
featureintomainstarted (MERGE_HEADpresent), conflict resolved and staged by hand, not yet committed (noindex.lockat that moment): one run of the script produced a two-parent merge commit with subjectautocommit: merge1 2026-10-28 15:26, clearedMERGE_HEAD, and pushed it toorigin main(ls-remote= the new merge HEAD). The user's unfinished merge — which they might still have wanted to test, amend, or abort withgit merge --abort— was finalized and published within a minute of staging the resolution. - Cherry-pick in progress — conflicting cherry-pick stopped (
CHERRY_PICK_HEADpresent), conflict resolved and staged: one run committed it asautocommit: cp1 …(the picked commit's own subject/message lost), clearedCHERRY_PICK_HEAD, and pushed it.
Why it matters
The repos this sweeps are personal working repos where merges and cherry-picks on the default branch are routine. Any conflict resolution that takes more than a minute while staged — i.e. essentially all of them, since the timer fires every 60 s — is silently committed under a meaningless autocommit: message and pushed to origin, with no chance to abort, squash, write a real message, or run a check first. For a merge, --abort becomes impossible once pushed; recovering means a revert or a history rewrite of a published branch.
Acceptance criteria
-
laptop-autocommit.shexits 0 without staging, committing, or pushing when a merge, cherry-pick, revert, or rebase is in progress in the target repo (state detected via the absolute git dir, per the laptop-repo-keeper: BUSY check never sees a merge/rebase in progress — rev-parse --git-dir is relative, so the keeper sealed a live merge as a 'snapshot' commit #1771 keeper fix — a worktree's.gitis a file, and.gitmay also be a submodule pointer). - The sequencer state (
.git/sequencer, e.g. a multi-commit cherry-pick/revert sequence paused between picks) is also treated as busy, or the issue's triage comment explicitly pins why the per-operation HEAD files suffice. - A test (shell test beside the script, in the style of
nixos/home/openclaw-backup.test.sh) covers: merge-in-progress → no commit,MERGE_HEADintact; cherry-pick-in-progress → no commit; ordinary tracked change → still committed and pushed (control). - No behaviour change for the clean-tree, detached-HEAD, off-default-branch, and index-locked cases.
Related: #1771 (same guard, keeper), #1751 (sibling sweep script committing more than its mandate — different script, different mechanism).
Activity
developing-today commentedon Oct 28, 2026
CODE-742
dezren39 commentedon Oct 28, 2026
🤖 Agent note · filed
e91098f1that nixos/home/laptop-autocommit.sh (the every-minute tracked-file sweep, laptop-autocommit.nix timers) has no merge/cherry-pick/rebase-in-progress guard — only an index.lock check (:11). Laptop probe with the verbatim script (sha256 e58fea91…, byte-identical in the laptop primary clone): control tracked change committed+pushed (PASS); a staged, unresolved-but-resolved merge on main was finalized as a two-parent "autocommit:" commit, MERGE_HEAD cleared, and pushed to origin; a staged cherry-pick resolution was likewise committed under an "autocommit:" subject (picked message lost) and pushed. The keeper sibling got this exact guard in laptop-repo-keeper: BUSY check never sees a merge/rebase in progress — rev-parse --git-dir is relative, so the keeper sealed a live merge as a 'snapshot' commit #1771 (laptop-repo-keeper.sh:65, absolute git dir).queue-packets/packet-1807.json(repo-health-code-pilot, triage); probe~/git/fleet/probe-2026-10-28-laneB-autocommit/(laptop); related laptop-repo-keeper: BUSY check never sees a merge/rebase in progress — rev-parse --git-dir is relative, so the keeper sealed a live merge as a 'snapshot' commit #1771, laptop-untracked-review: bare git commit sweeps pre-staged work into its commits — the junk-ignore commit also lands the newly tracked files and any unrelated staged edit #1751dezren39 commentedon Nov 3, 2026
task 2690 (repo-health-code-pilot, lane code-b): triage CONFIRMED on fresh main. nixos/home/laptop-autocommit.sh line 15 still checks only index.lock before add -u + commit (lines 19-25); the MERGE_HEAD mention at line 41 is post-pull conflict reporting, not a pre-commit guard, and no CHERRY_PICK_HEAD/REVERT_HEAD/rebase/sequencer check precedes the commit path. Mirror source verified fresh: laptop-repo-keeper.sh:76 BUSY guard (index.lock + MERGE_HEAD + rebase-merge + rebase-apply via absolute git dir). Existing laptop-autocommit-merge-abort.test.sh covers the pull-conflict abort, not this guard. Fix routed as task 6668 (small_fix, acceptance intact).
Merge pull request #4693 from developing-today/queue/6668-1807-autoco…
dezren39 commentedon Nov 3, 2026
task 6668 (repo-health-code-pilot, lane code-b): done. PR #4693 merged (merge commit 058bf72) — laptop-autocommit.sh now exits 0 untouched when MERGE_HEAD, CHERRY_PICK_HEAD, REVERT_HEAD, rebase-merge, rebase-apply, or sequencer state exists (absolute git dir, mirroring the keeper guard from #1771). New laptop-autocommit-in-progress.test.sh passes (merge + cherry-pick untouched, ordinary change still committed/pushed); existing merge-abort test passes; Codex review on head c63840b reported no findings. Basic guard check was pending fleet-wide at merge; merged under standing merge authority.