Rebase, Interactive Rebase, Cherry-Pick, Amend, and Safe History Editing: Diagnostics, Failure Modes, Security, and Performance

1. Rewrite diagnostic sequence

1. Preserve evidence: current OID, branch, reflog, remote-tracking refs, expected remote tip, and any review/deployment references.
2. Inspect status/refs/history/config: identify whether a rebase/cherry-pick sequencer is active.
3. Identify the affected layer: working tree/index conflict, local branch ref, old commit reachability, or remote published ref.
4. Choose the least destructive correction: abort an in-progress rewrite when uncertain; preserve old tips with a branch/tag before further surgery.
5. Verify graph/content and communicate changed OIDs before publishing replacements.

git status
git branch -vv
git log --graph --decorate --oneline --all --max-count=30
git reflog -12
git config --list --show-origin --show-scope
git for-each-ref --format='%(refname:short) %(objectname)' refs/heads refs/remotes

2. Failure mode — rebasing the wrong branch

The syntax git rebase topic means “rebase the current branch onto topic.” It does not mean “rebase topic onto whatever branch I am on.” In a disposable repository, if trunk is an ancestor of topic, running that command while on trunk can move trunk toward the topic history.

If you discover the mistake immediately, stop making more changes. Inspect the reflog and preserve the old tip:

git reflog trunk
git branch safety-trunk <old-trunk-oid-from-reflog>
git show --no-patch --oneline safety-trunk

Chapter 10 develops the full reset/recovery decision tree. Here the key skill is preserving the pre-rewrite OID before doing anything more invasive.

3. Failure mode — rewriting commits collaborators already consumed

A rebase can be locally perfect yet operationally destructive. Ask:

git branch -vv
git log --oneline origin/topic..topic
git log --oneline topic..origin/topic
git reflog topic
git ls-remote origin refs/heads/topic

If collaborators have based work, review comments, artifacts, or deployments on old OIDs, prefer additive correction or explicit coordination. A replacement push cannot update their local branches automatically.

4. Failure mode — accidentally dropping a commit during interactive rebase

A todo line can disappear because it was deleted accidentally. Configure a disposable lab with:

git config --local rebase.missingCommitsCheck error
git rebase -i trunk

If Git reports that commits were dropped accidentally, read the todo again with git rebase --edit-todo. Use an explicit drop action when omission is intentional. If the plan is uncertain, git rebase --abort restores the pre-rebase branch state.

5. Intentionally broken example — conflict during a cherry-pick

Two branches change the same line differently. Cherry-picking one change onto the other can produce output such as:

Auto-merging policy.ini
CONFLICT (content): Merge conflict in policy.ini
error: could not apply <oid>... Use red policy mode
hint: After resolving the conflicts, mark them with "git add/rm <pathspec>",
hint: then run "git cherry-pick --continue".
hint: You can instead skip this commit with "git cherry-pick --skip".
hint: To abort and get back to the state before "git cherry-pick",
hint: run "git cherry-pick --abort".

Interpretation line by line: Git could identify the file but not one unambiguous combined content; the selected source commit remains available through CHERRY_PICK_HEAD; the index/working tree hold conflict state; the sequencer is paused rather than silently choosing a side. The repair begins with:

git status
git diff
git show --oneline --stat CHERRY_PICK_HEAD

If you do not yet know the intended result, abort. If you do, edit the file deliberately, stage the resolution, inspect git diff --staged, and continue.

6. Failure mode — cherry-pick now, merge the source branch later

Cherry-pick creates a new commit that is not the same object as the source commit. Later merging the original source branch can leave two different commits representing the same logical change in ancestry. Content may merge cleanly because the patch is already present, but audit/release tooling can still encounter duplicate logical provenance.

Record why the cherry-pick was necessary, and use git log --cherry-mark or patch comparison tools when diagnosing patch-equivalent histories.

7. Failure mode — resolving the same idea repeatedly across a long rebase

Rebase replays commits one at a time. If many commits touch an area that changed upstream, you may resolve related conflicts repeatedly. This is not necessarily a bug: each historical patch is being applied in sequence to a different intermediate tree.

Before continuing dozens of times, verify that the series is worth preserving at that granularity. A smaller cleanup before rebasing can reduce repeated conflict cost. Git's rerere mechanism can reuse conflict resolutions and is covered with conflict engineering later in the course; do not enable unfamiliar automation mid-incident without understanding what it records.

8. Failure mode — plain force after rebase

Preserve and inspect the expected remote OID:

git fetch origin
git ls-remote origin refs/heads/topic
git log --graph --decorate --oneline --all --max-count=20

EXPECTED=<remote-oid-you-verified-before-rewrite>
git push --force-with-lease=refs/heads/topic:$EXPECTED origin topic:topic

If the lease fails, treat that as useful evidence that the remote ref is not what you expected. Fetch and investigate. Do not “fix the failure” by replacing the command with blind force.

9. Security consequences tied directly to history editing

• Secret incidents: rewriting history does not revoke a leaked token/key. Rotate/revoke first; secret-removal procedures come later.
• Signatures: recreated commits have new OIDs; old commit signatures do not authenticate replacements.
• Authorization: a server may reject force updates even with a valid lease because protected-ref policy is separate.
• Provenance: artifact attestations and deployment records keyed by old OIDs remain historical facts; rewriting Git does not rewrite those systems.

10. Performance where rebase mechanics matter

Long series can be expensive when Git must compare many upstream commits to detect clean cherry-picks or replay many conflict-prone patches. Current rebase documentation notes that some cherry-pick detection paths require reading upstream history and can be costly in large repositories. Avoid “rebase everything forever” policies; keep topic branches short-lived and choose history granularity that supports actual review/operations.

11. Red-zone operations while recovery evidence is unresolved

12. Symptom → first evidence → least destructive action

13. Knowledge check

14. Summary

History-editing incidents are solved by preserving OIDs and reflogs, identifying the ref that moved, aborting uncertain sequencer operations, and treating remote rewrite as coordinated state replacement. “Make the command succeed” is not the same goal as “preserve collaboration and provenance.”

Authoritative references

• git-rebase
• git-cherry-pick
• git-push
• git-reflog