Why does git rebase give every replayed commit a new SHA even when the content is identical?

## What Git actually hashes A commit's identifier is a hash of the commit object's bytes. Those bytes are, roughly: a pointer to the **tree** (the snapshot of the whole directory structure), zero or more **parent** pointers, an **author** line (name, email, timestamp), a **committer** line (name, email, timestamp), and the commit **message**. Change any byte in any of those fields and you get a different identifier. This is what makes Git history tamper-evident — a commit's name commits to everything about it, including its ancestry. The important implication for rebase: identical file content is not enough for an identical hash. Two commits with the same tree but different parents are different objects with different names. ## Why rebase must produce new objects Rebase's whole purpose is to change the base a series of commits sits on. The first commit in the replayed range is re-created with `main`'s current tip as its parent instead of the old fork point. That alone changes its bytes, and therefore its hash. The second commit is then re-created with the *new* first commit as its parent — so it changes too, regardless of whether anything else about it changed. The effect cascades: **every commit from the rebase point forward gets a new identity**, and so does every commit that descends from them. This is not an implementation quirk that a cleverer rebase could avoid. Making commit identity depend on ancestry is the design; a commit that kept its name while changing its parent would break the integrity property the whole model rests on. ## Author versus committer Rebase preserves the **author** fields — the person who originally wrote the change and when — and rewrites the **committer** fields to whoever is running the rebase, at the current time. This is why a rebased branch still shows original dates in `git log`'s default output while `git log --format=%cd` (committer date) shows today. It also means that even a hypothetical rebase where the parent happened to be unchanged would still yield a new hash, because the committer timestamp moved. ## What happens to the originals Rebase does not modify or delete the old commits — commits are immutable, so it cannot. It writes new objects and then moves the branch ref to the last new commit. The old chain is still in the object database; it is simply no longer reachable from the branch. It remains reachable from the reflog, which records the branch's previous positions, so `git reflog` plus a `git reset --hard` to the recorded hash restores the pre-rebase state exactly. Only once reflog entries expire and garbage collection runs do the unreferenced objects actually go away. ## The consequences people care about - **Force-push.** The remote still points at the old chain. Your new tip is not a descendant of it, so the push is not a fast-forward and is rejected unless forced. - **Teammates diverge.** Anyone holding the old commits now has commits that no longer exist upstream, and a naive pull produces a merge of the old and new copies — the duplicated-commits mess that follows an unannounced rebase. - **External references rot.** Anything that recorded the old hashes — build records, links, notes, a `git bisect` session in progress — refers to commits that are no longer on the branch. - **Signatures.** A signature covers the commit object; re-creating the object invalidates any signature it carried unless the rebase re-signs. ## Detecting equivalence anyway Even though the hashes differ, Git can tell that a replayed commit introduces the same change as its original: it computes a **patch-id**, a hash of the change itself rather than the commit object, and uses it to notice duplicates. That is how a rebase can skip commits already present upstream and report that a commit became empty. So "the SHA is different" and "Git cannot tell they are the same change" are two separate statements — the first is true, the second is not. ## The takeaway to state in an interview Rebase copies rather than moves, because identity includes ancestry. Almost every practical rebase question — why force-push, why teammates suffer, why the originals are recoverable — is a corollary of that one sentence, and being able to derive them on the spot is what distinguishes a mechanical understanding from a memorised list.