> Eventually, I figured out that it was operating on diffs, not snapshots
The snapshot include all the history that led to the current snapshot. So even if you did a squash instead of dropping, you're changing everything that depends on that
> The snapshot include all the history that led to the current snapshot
Git snapshots don't contain any history, other than the commit chain (reference to the parent commit/s) in the commit object. While the storage format is a bit complex, they behave fundamentally like a copy of the working tree at the point of commit.
> So even if you did a squash instead of dropping, you're changing everything that depends on that
Squashes don't change the subsequent commits/snapshots either, other than the commit ID and chain. The tree itself remains untouched. You can verify this.
Yes, but since they change the commit id, and since each commit has a pointer to its parent commit, you have to rewrite all the commit objects, even if the tree doesn't change.
The context of my first comment is about how a rebase affects the contents of the tree. It's about predicting what happens to subsequent snapshots. Bringing commit ID and parent commit into that context complicates and obscures the point I'm trying to convey.
The snapshot include all the history that led to the current snapshot. So even if you did a squash instead of dropping, you're changing everything that depends on that