git-history-surgerylisted

# Git History Surgery ## When to invoke Trigger on any of: - "split this commit into smaller ones" (after a push) - "rebase this into atomic commits" - User points out a bulk commit and asks to fix history - You bulked a multi-concern change into one commit and caught it before/after pushing ## Why a throwaway worktree Doing `git reset --soft HEAD~1` in an *existing* worktree is risky: - Another session might be on the same repo in a different worktree/branch. Your reset doesn't affect them, but switching branches there will. - If the worktree you're in isn't on the branch you think (e.g. ops/main worktree was on `fix/usage-async-load` in a past session), a reset rewrites the *wrong* branch. - Existing worktrees may carry uncommitted state you'd lose. **The safe pattern: fresh detached worktree at origin/<branch>, do surgery, push, discard.** ## The pattern ```bash # 1. Create throwaway worktree at the exact commit you want to rewrite TMPWT=$(mktemp -d -t history-split-XXXXXX) git fetch origin git worktree add --detach "$TMPWT" origin/<branch> cd "$TMPWT" # 2. Verify you're where you expect git log -3 --oneline # 3. Undo the commit(s) keeping working-tree content git reset --soft HEAD~1 # or HEAD~N for multiple git reset # unstage so you can stage atomic chunks # 4. Reset the file(s) to the *pre-change* base, then rebuild with Edits git checkout HEAD -- <path> # 5. Apply atomic change → stage → commit → repeat (N times) # Each commit = one visu