> Git commits are stored on disk as snapshots, but that's not necessarily how Git treats them! Various Git commands treat a commit as either a complete repo sna

> Git commits are stored on disk as snapshots, but that's not necessarily how Git treats them! Various Git commands treat a commit as either a complete repo snapshot or as a change set, depending on what you’re doing. The problem is that the documentation and the developers go between these modes so fluently that you have to know the context in order to distinguish them. Of course to them it's obvious that you are treating the incoming changes as a “changeset” since it's a diff (a patch) from an email (not a snapshot). This is the “name” section for `man git-rebase`. > git-rebase - Reapply commits on top of another base tip How should someone new guess that this means to (effectively) take the diff of each commit and applying those changes? Instead of working on the snapshots?[1] Because I think you could also interpret it as: take the tree (the snapshot) of each of these commits and make an alternative subgraph where the parents are different, propagating from the new base tip. Which means that you can make a new root commit (disregarding old history by “squashing” seems to be popular on SO for some reason) starting from A by rebasing A on `--root`. But it doesn't work like that. If you want to do that you should instead use git-replace. In my experience, for every little question about cherry-picking or rebasing, you have to go down to the fundamental concepts. Because the way people work is not like a sponge which only absorbs the information that it is given; people learn 10% about something and then automatically infer the rest, and sometimes 50% of that is wrong. So then you have to unnest that. I guess this is my long-winded way of agreeing with the author. [1] Working on the snapshots would also be useful. You could use that to format all of the commits on the branch.