Conversation
…e file `drop`, `reword`, `swap`, `update` and fold's rewriting paths put the saved patch back on the `Completed` arm and delete their state file after, so a delete that fails still leaves the index as the user had it. `commit` and `absorb` kept the restore inside `post_commit`/`post_absorb`, which run after the delete: a failed delete returned first and left the staged work unstaged, where only `loom continue` would have put it back — on a command that had just succeeded. The restore moves to both call sites of each helper, the way `update` does it, and the `post_*` helpers go back to reporting only. Fold's uncommit path keeps the restore last and now says why: the apply it guards undoes itself by diffing the working tree against the index. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Change-Id: I6a955eaa34655c124af7aaf45ab4ca2475d0deba
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (5)
Included review availability: Your plan provides up to 10 included reviews per hour; 7 remain after this review. 📝 WalkthroughWalkthroughThe change moves staged-change restoration before transaction deletion on completed and resumed rebase paths. Absorb and commit post-processing helpers no longer restore staged changes. Documentation records the fold uncommit exception and restoration behavior. ChangesStaged restoration ordering
Priority: ⬇️ Low Estimated code review effort: 2 (Simple) | ~10 minutes Change: Bug fix Suggested reviewers: Merge Risk: ⚪ Minimal · up to No actionable merge-blocking risk remains in the staged-restoration ordering changes. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Comment |
drop,reword,swap,updateand fold's rewriting paths put the savedpatch back on the
Completedarm and delete their state file after, so adelete that fails still leaves the index as the user had it.
commitandabsorbkept the restore insidepost_commit/post_absorb, which run afterthe delete: a failed delete returned first and left the staged work unstaged,
where only
loom continuewould have put it back — on a command that hadjust succeeded.
The restore moves to both call sites of each helper, the way
updatedoesit, and the
post_*helpers go back to reporting only. Fold's uncommit pathkeeps the restore last and now says why: the apply it guards undoes itself by
diffing the working tree against the index.
Co-Authored-By: Claude Opus 5 (1M context) noreply@anthropic.com
Change-Id: I6a955eaa34655c124af7aaf45ab4ca2475d0deba
Summary by CodeRabbit
Bug Fixes
Documentation