Symptom#

Before an interactive rebase you create a backup branch at the current tip (git branch backup/before-rebase). After the rebase, the backup branch no longer points at the old commits: the rebase moved it along with the rewritten history, and in the observed case it was gone.

Cause#

rebase.updateRefs = true (or --update-refs) makes a rebase update every local branch that points at a commit inside the rebased range, so stacked branches follow the rewrite. A backup branch at a rebased commit is such a branch, so the rebase rewrites it instead of leaving it on the old commit.

Fix#

Keep the backup as a tag (git tag before-rebase), which rebase never moves, or run that rebase with --no-update-refs. Check the backup with git log -1 <backup> after the rebase, and recreate it from the reflog (git reflog, ORIG_HEAD) if it moved.

Evidence#

A dotfiles repository with rebase.updateRefs set in the user's git config, 2026-09-26: the backup branch made before an interactive rebase was moved and then missing, and was recreated at the old tip.