Undoing a Bad Rebase

A rebase rewrites commits, so a mistaken one is the scariest accident, and just as easy to undo. Sam adds a second commit to the cover experiment and means to rebase it onto main, but types the release branch:

git switch -q experiment/covers
# Edit public/index.html: smaller text in the placeholder
git commit -qam "Shrink the placeholder text"
git rebase -q release/1.1
git log --oneline -3
git reflog -3 --format='%h %gd %<(40,trunc)%gs' experiment/covers
git reset --hard experiment/covers@{1}
git switch -q main

hint: use --reapply-cherry-picks to include skipped commits
hint: Disable this message with "git config set advice.skippedCherryPicks false"
1d63a39 Shrink the placeholder text
d732774 Show a cover placeholder for each book
2a8d222 Restore cents in prices: NUMERIC(8) meant whole dollars
1d63a39 experiment/covers@{0} rebase (finish): refs/heads/experiment..
6eab87e experiment/covers@{1} commit: Shrink the placeholder text
c7ba56f experiment/covers@{2} branch: Created from HEAD@{1}
HEAD is now at 6eab87e Shrink the placeholder text

Git 1,932 replayed everything the branch had that release/1.1 lacked: the two cover commits and seven commits of main since 1.1.0, as new copies such as 2a8d222. It skipped the limit fix, whose patch was already cherry-picked there; that is what the hint means (%<(40,trunc) just shortens the reflog messages). The branch's reflog records the whole rebase as one entry, so experiment/covers@{1} is the branch exactly as it was before; HEAD's reflog, by contrast, lists every replayed commit. During a rebase that is still running, git rebase --abort is the simpler undo (Abort and Continue).