Abort the run when a git/gh command fails unexpectedly#52
Open
Phlogistique wants to merge 6 commits into
Open
Conversation
…esolution
If origin/<old base> was deleted while a child PR sat in conflict
(auto-delete head branches left enabled despite the README, or manual
deletion), the resume merge failed with "not something we can merge" and
git merge --abort failed too ("There is no merge to abort"). The run then
exited nonzero after re-posting the misleading conflict comment and the
label, repeating on every push. (Not a mid-function set -e kill:
update_direct_target is called in an if condition, which suppresses
errexit; observed via the new test scenario.)
Check origin/<old base> up front like #39 did for the target branch, and
only run git merge --abort when MERGE_HEAD exists.
https://claude.ai/code/session_01STkeSJ7cLrmrNn4aTDYkwH
set -e is suppressed inside if/&&/|| conditions and everything they call, including the whole body of update_direct_target, which both entry points invoke as a condition. So most failures there fell through silently: a failed git checkout let the merges and the final git reset --hard run on the previously checked-out branch (corrupting it, in main's loop over several child PRs), and a failed git commit-tree let the function return success, after which main retargeted the PR onto a base its head does not contain. A failed conflict comment still added the label, leaving a resume with no state marker. Every log_cmd call site now states its failure policy: run (log, execute, die on failure; die's explicit exit aborts from any context) or try (log, execute, hand the status to the caller) for the merges whose failure is an expected outcome. set -e stays as a backstop only. https://claude.ai/code/session_01STkeSJ7cLrmrNn4aTDYkwH
Collaborator
Author
|
huh how come this wasnt updated automatically? |
Re-applied onto the restructured script: the merge --abort guard and the origin/OLD_BASE existence check (now via the PR-number abandon_resume). The regression test becomes scenario F, adapted to the PR_BASE payload. https://claude.ai/code/session_01STkeSJ7cLrmrNn4aTDYkwH
Phlogistique
added a commit
that referenced
this pull request
Jun 11, 2026
#55) If `origin/<old base>` was deleted while a child PR sat in conflict (auto-delete head branches left enabled despite the README, or manual deletion), the resume merge failed with "not something we can merge" and `git merge --abort` failed too ("There is no merge to abort"). The run then exited nonzero after re-posting the misleading conflict comment and the label, repeating on every push. (Not a mid-function `set -e` kill: `update_direct_target` is called in an `if` condition, which suppresses errexit; observed via the new test scenario.) Check `origin/<old base>` up front like the existing target-branch check, and only run `git merge --abort` when `MERGE_HEAD` exists. Base of the stack continued in #52 and #53. https://claude.ai/code/session_01STkeSJ7cLrmrNn4aTDYkwH --- _Generated by [Claude Code](https://claude.ai/code/session_01STkeSJ7cLrmrNn4aTDYkwH)_ Co-authored-by: Claude <noreply@anthropic.com>
|
github-actions
Bot
added
the
autorestack-needs-conflict-resolution
…on main Re-applied the run/try/die conversion over the restructured script: the helpers from the PR-number and merge-method work are converted too, and the explicit read-failure aborts in read_state_marker / pr_has_conflict_label become die (regression scenarios G and H). list_child_prs gets try, not run: its callers consume it through a process substitution, which swallows the status either way. https://claude.ai/code/session_01STkeSJ7cLrmrNn4aTDYkwH
github-actions
Bot
changed the base branch from
claude/git-merge-abort-crash-sc64z6
to
main
github-actions
Bot
removed
the
autorestack-needs-conflict-resolution
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
set -eis suppressed insideif/&&/||conditions and everything they call, including the whole body ofupdate_direct_target, which both entry points invoke as a condition. So most failures there fell through silently: a failedgit checkoutlet the merges and the finalgit reset --hardrun on the previously checked-out branch (corrupting it, in main's loop over several child PRs), and a failedgit commit-treelet the function return success, after which main retargeted the PR onto a base its head does not contain. A failed conflict comment still added the label, leaving a resume with no state marker.Every
log_cmdcall site now states its failure policy:run(log, execute, die on failure; die's explicitexitaborts from any context) ortry(log, execute, hand the status to the caller) for the commands whose failure is an expected outcome. The explicit read-failure aborts from #50 becomedietoo, with regression scenarios for both reads.set -estays as a backstop only.https://claude.ai/code/session_01STkeSJ7cLrmrNn4aTDYkwH
Generated by Claude Code