4 ms·
IMO managing revisions makes more sense than managing patches. Yes yes, I know about commutative patches and all that, and no I don't need that. I do reorder
by cryptonector 2y ago
IMO managing revisions makes more sense than managing patches. Yes yes, I know about commutative patches and all that, and no I don't need that. I do reorder patches sometimes, and when they yield the same tree that's interesting, but not that interesting.
- remram 2y agoYou need both. Even with Git (a snapshot-based system), some commands take a hash as a revision and some take a hash as a change (e.g. checkout/rebase/reset/bisect vs cherry-pick/revert/amend). You'll hear both in common parlance too ("this commit doesn't pass tests"/"this commit is deployed"/"rebase onto this commit" vs "I did the last commit"/"this commit is too big"/"that commit broke X"). You really have to think of commits as both, neither view is entirely sufficient.
- cryptonector 2y agoI only think of commit hashes. Branches and tags and any refs are just names for commit hashes.
- remram 2y agoWe were never talking about branches and tags. I think possibly you don't know what "revision" means? A commit hash identifies both a patch or a revision, that's my point.
- cryptonector 2y ago> A commit hash identifies both a patch or a revision, that's my point. Strictly speaking, no. A commit hash identifies a tree. There is no patch stored, nor is a patch bound into the commit hash in any way. The patch is indirectly implied as the differences between the new commit's tree hash and the preceding commit's tree hash.