> I think you're muddling the concepts of tree (a snapshot) and commit somewhat. A commit is not merely a snapshot, it's a tree as well as metadata. My intenti

> I think you're muddling the concepts of tree (a snapshot) and commit somewhat. A commit is not merely a snapshot, it's a tree as well as metadata. My intention was to approximate definitions to the bare essentials without losing too much fidelity. This criticism feels like a nitpick (apologies if that wasn't your intention) because the metadata was implied as it's well understood. > If by commit you mean tree, then yes. One can think of B and B~ "introducing" the same changes if the diff between A and B is the same as A~ and B~. That is the diff model. You are cautioning against treating commits as diffs during rebasing, and yet insist on using that definition to oppose my notion. My stand is a bit more consistent here. Treat commits as snapshots. But rebase and similar operations use diffs on those snapshots. > Change A-B-C to A-C~-B~ and very often you'll find yourself "introducing" changes from B in C~ I find this claim bizzare. The change works exactly as expected when viewed as diff (3way merge) operations. The diffs introduced by C and (B -> B~) end up in commit B~ (tree snapshot + metadata and whatever else necessary - just to be pedantic).