A rebase would change all commit hashes, all the way to the base branch. Your commit hash in the comment would not be relevant.

Git UIs should expose the tree hash as well to mitigate that issue.

That wouldn't help. If you needed to rebase (there was a conflict) then the tree hash will necessarily be different. In fact, unless you are rebasing on a commit and it's reversion then you'll probably get a different tree hash.

Indeed. What I'm looking for isn't the tree hash it's the hash of the patch itself. I don't think that's explicit anywhere.

Patches in git are generated on-the-fly. This is actually one of the critical things that made git so much better than conventional version control systems at the time -- it doesn't need to track diffs (which means it doesn't have to handle the infinite fractal of problems that spiral out of rebasing diffs). It can just compute them when it needs them.

Think of git like a snapshotting filesystem that has a VC interface added on top.

Where does that leave rebasing, then? That's explicitly an operation on diffs: take these diffs and apply them to that.

Rebasing is implemented by generating diffs, yes. But git doesn't actually store these diffs -- they're all generated on the fly from tree snapshots. If your VC stores diffs rather than the actual contents of files then you can't be sure that you'll get out exactly the same data as you put into it. There are also a bunch of other problems that happen as a result.