3 ms·
You 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/bis
by remram 2y ago
You 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.