In the author’s algorithm there is no two branches. The following diagram is an undo tree where we made change B, went back to A, then made C C ——— now

In the author’s algorithm there is no two branches. The following diagram is an undo tree where we made change B, went back to A, then made C C ——— now / —— A \ B But time doesn’t branch, so our history shouldn’t /have to/ branch. What if our undo was itself part of the linear history? Then we could build up the history like this: A A —— B A —— B —- undo_B A —— B —— undo_B —— C For complex undo/redo scenarios this could get out of hand. A — B — undo_B — C — undo_C — undo_undo_B —undo_B — undo_A… But the author (I think correctly) states that for the average user this behavior is intuitive and desired. They also added the optimization that undoing and then redoing a set of changes doesn’t make it into the history, as it’s basically a no-op.