When commit history is rewritten, what happens to the original commits?

## Why nothing can be edited in place A commit's identifier is derived from its own contents - the file snapshot, the parent link, the authorship metadata, the message. That makes editing a stored commit impossible in a strict sense: change any of it and what you have is a different commit with a different name. Immutability here is not a policy someone chose to enforce; it falls out of how commits are named. So every operation described as "rewriting history" - correcting a message, combining several commits into one, splitting one into two, dropping a commit, removing a file that should never have been recorded - does the same thing underneath. ## What a rewrite actually does 1. **Read the content you want to end up with**, taken from the commits that already exist. 2. **Build new commits** carrying that content. Each gets a new identifier, because the content, the parent link, or the message differs from the original. 3. **Move the line's pointer** from the old newest commit to the new one. A line of development is a movable pointer, and the rewrite repoints it. 4. **Leave the old commits exactly where they are.** They are still stored. Nothing references them any more, which is a very different thing from being deleted. 5. **Wait for cleanup.** Unreferenced objects are removed by a maintenance pass after a grace period rather than at the moment of the rewrite. That is why work that felt lost immediately after a rewrite has usually not gone anywhere yet - though the window is a grace period, not a guarantee. The sentence worth having ready in an interview: *a rewrite adds commits and moves a pointer; it never modifies a commit.* ## The cost is social, not technical Building the new commits is cheap and essentially instant. What varies by orders of magnitude is who else is already holding the old identifiers. | Who holds the old commits | What the rewrite costs | |---|---| | Only your own machine | Nothing. Reshape as much as you like. | | Shared, but nobody has taken them yet | Little - the next person to take the line simply gets the new shape | | Shared, and teammates already have them | Every teammate must deliberately repoint their copy; anyone who takes the line naively ends up holding both shapes of the same work | | Teammates have built new work on top | Expensive - their commits' parent chains reference commits the shared line no longer carries | | A deploy, ticket or incident record cites an old identifier | The reference resolves only for as long as the old commit survives cleanup | This is the whole reason for the rule of thumb candidates recite: rewrite freely while the work is yours alone, and treat rewriting a shared line as a coordination event rather than a tidy-up. ## A rewrite that goes wrong A bike-share operations team of 11, 6 of them hired within the last quarter, keeps a shared integration line. The median wait for a review is 2 days, so at any moment several people have already taken the line and are working on top of it. An engineer decides that 4 messy commits on that line should have been 1, rewrites them, and repoints the line. Nothing breaks for them. For everybody else, the next time they take the line, their copy now contains both the 4 original commits - which they already had - and the 1 replacement describing the same work again. The newly-hired half of the team, who have never seen this, untangle the result by hand and in several different ways, and one of them silently reintroduces a change the rewrite was meant to remove. The technical operation took under a second; the cleanup took the rest of the day. The failure was not the rewrite. It was repointing something other people were standing on without telling them. ## What good practice looks like - **Rewrite before you share, not after.** Tidying a series while it is still local is free and makes the shared history better for everyone who reads it later. - **When a shared rewrite is genuinely necessary** - a credential recorded by accident, content that must be removed - announce it, agree a moment when nobody is mid-change, say exactly which line and which commits are affected, and tell every holder what to do with their copy. - **Never assume other copies update themselves.** Nothing propagates a rewrite. Each holder of the old commits acts, or keeps the old shape indefinitely. - **Remember that a rewrite does not erase.** A secret committed by accident and then rewritten out is still stored locally until cleanup, still present in every copy anyone already took, and possibly still present in any system that mirrored or built from that line. Rewriting is not a substitute for rotating the secret - rotate it. - **Expect external references to dangle.** Tickets, deploy records and chat links citing an old identifier stop resolving once cleanup runs. ## What the interviewer is checking A candidate who says "you should never rewrite history" has memorised a slogan. A candidate who says "a rewrite creates new commits and moves a pointer, so the question is always who else is holding the old ones" has the model, and can then reason about a case the slogan does not cover - which is what the scenario is really testing.