Repository navigation
Report a signing failure from restack's rebase and get past it - #30
Merged
DomBlack merged 1 commit intoOct 9, 2026
Merged
Conversation
There was a problem hiding this comment.
🟡 Changes recommended
The fallback commit can unexpectedly execute hooks that ordinary rebase picks bypass.
1 open finding
What changed in this PR
Adds signing-failure handling and recovery for restack rebases.
Changes:
- Detects rebase signing failures and returns actionable
signing_failederrors. - Commits staged failed picks before continuing the rebase.
- Adds coverage and updates MCP guidance.
| File | Description |
|---|---|
pkg/git/rebase.go |
Detects and recovers rebase signing failures. |
pkg/git/objects.go |
Clarifies commit-tree signing behavior. |
pkg/git/commit_test.go |
Tests rebase signing recovery. |
pkg/app/staging.go |
Maps signing errors to recovery steps. |
pkg/app/restack.go |
Applies signing-error mapping during restacks. |
pkg/app/restack_test.go |
Tests restack failure, continuation, and abort. |
pkg/app/mutate_test.go |
Tests modify signing failures. |
pkg/mcp/instructions.go |
Adds MCP recovery guidance. |
docs/mcp.md |
Documents rebase signing failures. |
🧠 Review effort: Balanced
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
DomBlack
force-pushed
the
signing-failures-in-restack
branch
from
October 9, 2026 17:00
fa2577a to
c1528fb
Compare
DomBlack
force-pushed
the
signing-failures-in-restack
branch
from
October 9, 2026 17:17
c1528fb to
3340de4
Compare
Comment on lines
+179
to
+180
| if se := c.signingError(ctx, repo, stderr); se != nil { | ||
| return false, se |
Owner
Author
There was a problem hiding this comment.
Done, the type's doc now says what state each path leaves: untouched index from Commit, rebase in progress with the pick staged from a rebase.
The conflict path of a restack is a real git rebase, and a rebase signs every commit it replays, so a key git can't use stops it on the first pick. We read any rebase still in progress after a non-zero exit as a conflict stop, so the user was told to resolve files from merge-tree that weren't conflicted at all, and never that the key needed unlocking. Worse, git won't continue over the failed pick: it leaves the changes staged and says to commit them yourself, so continue was stuck even once the key was loaded. The rebase outcome now spots git's signing marker and returns the same SigningError commit does. Restack and continue map it to signing_failed with the ssh-add line, and continue and abort as the next steps; the rebase is left where it is so abort still puts the moved branches back. Continue does what git's hint says: when rebase --continue refuses because the failed pick is still staged, it commits it (git keeps the pick's author and message in its own state and then drops the rescheduled pick as already applied) and continues again. Modify's amend already came through the commit path; it now has a test proving it. While testing this I found commit-tree doesn't honour commit.gpgsign at all, whatever its docs say, so the native replay never needs the key. Its comment claimed the opposite and now says what it actually does.
DomBlack
force-pushed
the
signing-failures-in-restack
branch
from
October 9, 2026 17:37
3340de4 to
7de1735
Compare
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
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.
The conflict path of a restack is a real
git rebase, and a rebase signs every commit it replays, so a key git can't use stops it on the first pick. We read any rebase still in progress after a non-zero exit as a conflict stop, so the user was told to resolve files from merge-tree that weren't conflicted at all, and never that the key needed unlocking. Worse, git won't continue over the failed pick: it leaves the changes staged and says to commit them yourself, so continue was stuck even once the key was loaded.The rebase outcome now spots git's signing marker and returns the same
SigningErrorcommit does. Restack and continue map it tosigning_failedwith thessh-addline, and continue and abort as the next steps; the rebase is left where it is so abort still puts the moved branches back. Continue does what git's hint says: whenrebase --continuerefuses because the failed pick is still staged, it commits it (git keeps the pick's author and message in its own state and then drops the rescheduled pick as already applied) and continues again. Modify's amend already came through the commit path.While testing this I found
commit-treedoesn't honourcommit.gpgsignat all, whatever its docs say, so the native replay never needs the key. Its comment claimed the opposite and now says what it actually does.