Hacker News new | ask | show | jobs
by cyphar 3482 days ago
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.
1 comments
couchand 3482 days ago
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.
link
cyphar 3482 days ago
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.

link
couchand 3482 days ago
Where does that leave rebasing, then? That's explicitly an operation on diffs: take these diffs and apply them to that.
link
cyphar 3481 days ago
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.
link