[dcousens]

Honestly, just being able to "tick" each commit would be great. On https://github.com/bitcoin/bitcoin/ it is common practice to include the commit hash in your approval comment so you can easily review where you were up to if a rebase occurs.

[rcaught]

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

[couchand]

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

[cyphar]

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.

[couchand]

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.

[cyphar]

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.

[couchand]

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