4 ms·

I think this is incorrect, no? Can’t all commits be turned into patches? Thus, aren’t commits isomorphic to diffs?

by breck 6y ago

divbzero 6y ago
If you inspect the files in the .git directory, you’ll find commits stored as trees of directory and file objects. But it is true that they can be converted diffs on the fly, which is exactly what the git show command does.
lann 6y ago
> aren’t commits isomorphic to diffs? Nearly, though renames are only approximately extracted from the snapshots.
- jepler 6y ago
  If your VC isn't plumbed all the way into your editor, you can't tell changing a typo from deleting and re-typing the whole file when it comes time to create a delta.
  - lann 6y ago
    There is a `git mv` command that means "rename". Git could (even with its current data model) explicitly annotate commits with this intent, but doesn't. I don't know how useful that would be compared to the current heuristics, but it does mean that git commit "snapshots" are not (quite) isomorphic to a diff format (like posix diff's) that can explicitly encode renames.
tomtomtom777 6y ago
Consider a small commit with spelling error. If I turn this into a patch and apply it to another branch it will be a different commit even it will be the same patch. As such, the concept of a "commit" in Git refers to a complete state of everything; a snapshot.
jepler 6y ago
Yes,-ish. However, there's also the question of what operations are efficient. (Diff feels very performant in git but) maybe having the diffs as the first-class objects enables doing something efficiently that git doesn't do. (perhaps, identifying when identical patches have occurred in different portions of the history?) I've used several patch-based VCs (RCS and CVS) but I think they pre-date this "sound theory of patches" and instead the use of patch-style representation was for optimizing storage. (just as git uses packs and deltas to optimize storage and performance, f'rinstance) So I don't really know what I'm missing. (If the sound theory of patches would let me better understand what occurred at a merge commit than git's tooling, that'd be just about enough to sell me on switching. except for the network effects of git & github.)
johntb86 6y ago
That's true, but git doesn't natively have a way to refer to a single diff. You can use a hash to refer to a commit, but that depends on the entire history up to that point. If you rebase a commit then the hash changes, even if the new commit is semantically the same.
- jdoliner 6y ago
  It kinda does, `git show <commit>` does exactly what one would expect if commits were actually diffs. That is it shows the diff between <commit> and its parent.
jdoliner 6y ago
It's technically correct. The key thing here is that it's isomorphic. You can either have a system of commits in which diffs are computed between commits or a system of diffs in which commits are computed by applying diffs. The trade-offs are in performance of various operations, not in the user exposed semantics. Git chooses to have its first class object be commits and diffs are computed on the fly. So again it's technically correct, but in practice commands like cherry-pick, which treats a commit like a diff between that commit and its parent really blur the line. I think in reality you can be a really advanced git user and not even realize that there's a difference between a commit based and diff base version control system, because in practice there really isn't much of a difference.

I think this is incorrect, no? Can’t all commits be turned into patches? Thus, aren’t commits isomorphic to diffs?

by breck 6y ago

I think this is incorrect, no? Can’t all commits be turned into patches? Thus, aren’t commits isomorphic to diffs?

If you inspect the files in the .git directory, you’ll find commits stored as trees of directory and file objects. But it is true that they can be converted diffs on the fly, which is exactly what the git show command does.

lann 6y ago

> aren’t commits isomorphic to diffs? Nearly, though renames are only approximately extracted from the snapshots.

jepler 6y ago
If your VC isn't plumbed all the way into your editor, you can't tell changing a typo from deleting and re-typing the whole file when it comes time to create a delta.
- lann 6y ago
  There is a `git mv` command that means "rename". Git could (even with its current data model) explicitly annotate commits with this intent, but doesn't. I don't know how useful that would be compared to the current heuristics, but it does mean that git commit "snapshots" are not (quite) isomorphic to a diff format (like posix diff's) that can explicitly encode renames.

tomtomtom777 6y ago

Consider a small commit with spelling error. If I turn this into a patch and apply it to another branch it will be a different commit even it will be the same patch. As such, the concept of a "commit" in Git refers to a complete state of everything; a snapshot.

jepler 6y ago

Yes,-ish. However, there's also the question of what operations are efficient. (Diff feels very performant in git but) maybe having the diffs as the first-class objects enables doing something efficiently that git doesn't do. (perhaps, identifying when identical patches have occurred in different portions of the history?) I've used several patch-based VCs (RCS and CVS) but I think they pre-date this "sound theory of patches" and instead the use of patch-style representation was for optimizing storage. (just as git uses packs and deltas to optimize storage and performance, f'rinstance) So I don't really know what I'm missing. (If the sound theory of patches would let me better understand what occurred at a merge commit than git's tooling, that'd be just about enough to sell me on switching. except for the network effects of git & github.)

johntb86 6y ago

That's true, but git doesn't natively have a way to refer to a single diff. You can use a hash to refer to a commit, but that depends on the entire history up to that point. If you rebase a commit then the hash changes, even if the new commit is semantically the same.

jdoliner 6y ago
It kinda does, `git show <commit>` does exactly what one would expect if commits were actually diffs. That is it shows the diff between <commit> and its parent.

jdoliner 6y ago

It's technically correct. The key thing here is that it's isomorphic. You can either have a system of commits in which diffs are computed between commits or a system of diffs in which commits are computed by applying diffs. The trade-offs are in performance of various operations, not in the user exposed semantics. Git chooses to have its first class object be commits and diffs are computed on the fly. So again it's technically correct, but in practice commands like cherry-pick, which treats a commit like a diff between that commit and its parent really blur the line. I think in reality you can be a really advanced git user and not even realize that there's a difference between a commit based and diff base version control system, because in practice there really isn't much of a difference.