3 ms·

Note that git does work with diffs a lot. Rebases and cherry-picks work by applying diffs, not by copying blobs. Auto-merging also needs to look at file conten

by tux3 5y ago

Note that git does work with diffs a lot. Rebases and cherry-picks work by applying diffs, not by copying blobs. Auto-merging also needs to look at file content as text, you can't auto-merge a binary file with git. It's an often repeated fact that if you look inside Git, it doesn't work with diffs, it works with blobs. But if you look closer, it's often diffs again!

arghwhat 5y ago
With cherry-picks (and thus rebase), you ask git to turn a commit into a patch, so it does just that. I would mostly consider auto merges (which I guess are bolted on) as the main area where git itself uses diffs during resolution and even then only as a suggested resolution (you get warned and need to confirm it when validating the merge). So no, it's blobs all the way down. Darcs and Pijul are patch based though.
- tux3 5y ago
  It's true that git is blob based, as opposed to patch based, but it's not the full picture! In practice, git stores a lot more diffs (or rather, deltas) than it stores loose blobs. (And you probably know this already, but I feel it's still worth making explicit) This is necessary, because when a repo accumulates commits, it becomes a lot more efficient to store most of the objects as deltas instead of separate blobs. If Git didn't do this, it would have a lot of copies, and they would take a lot of space. So the fundamental model of git is truly based on blobs in theory, but in practice many or most git commands will operate on packfiles, and if you look in your .git object store, most likely you will have a few big packfiles containing most objects, and then a much smaller collection of loose blobs. All those diffs are what the "resolving deltas" progress indicator that people see when they do a big clone, fetch, or checkout is about =)
  - ori_b 5y ago
    > In practice, git stores a lot more diffs (or rather, deltas) than it stores loose blobs. The diffs it stores are not the diffs you see in git diff. They're rolling checksum based chunks. The data that the delta is computed against is picked with a heuristic ("sort by name and date, try the top 10, and use the smallest result"). And, in practice, the heuristic diffs the older files against the newer ones, rather than diffing in chronological order, so that getting recent data doesn't involve a lot of delta application. The git deltification is better thought of as a compression method than as diffing.
  - arghwhat 5y ago
    Packfiles and deltas are a storage and transfer optimization for blobs. Any access to them store and yield blobs. It is for all intents and purposes just an internal serialization format, akin to how a filesystem is just a serialization format that makes all your data one large stream. One generally talks about the provided interface (files for a filesystem, blobs for git) rather than where the bits actually go. Compression algorithms are also to some extend diffs as they serialize to a sequence of "repeat previous segment and add this new data" commands, but it is not useful to consider them as such.
- cryptonector 5y ago
  Merges, rebases, cherry-picks, are all the same kind of thing. A merge is essentially a rebase that squashes all the commits being picked.
  - arghwhat 5y ago
    No, a merge works very differently. A merge is a commit with two parent commits, pointing to a new tree that contains the blobs from both parents. It does not modify any blobs, nor does it modify the parent commits. The full history of all activity is retained. A merge conflict is a case where both trees changed the same blob since their common ancestor. In this case, you have to make a new blob yourself (the "resolution") for use in the merge commit's tree, instead of using one of the parent blobs. Squash is "Remove all commits from C_newest to C_oldest, and create a new commit using C_newest tree". Rebases just run another git action for every commit in a sequence, e.g. cherry-pick.
    - cryptonector 5y ago
      > A merge is a commit with two parent commits, pointing to a new tree that contains the blobs from both parents. The second parent is metadata. The way a merge works is essentially to compute the commits you need to cherry-pick, then cherry-pick them without committing, resolving conflicts in pretty much the same way git cherry-pick does, THEN commit with two parents. > It does not modify any blobs, nor does it modify the parent commits. The full history of all activity is retained. A new commit containing merged content is created, as well as a merge commit with the second parent that documents that a merge happened and what was merged. > A merge conflict is a case where both trees changed the same blob since their common ancestor. In this case, you have to make a new blob yourself (the "resolution") for use in the merge commit's tree, instead of using one of the parent blobs. git merge does the same thing for automatic (and manual) conflict resolution as git cherry-pick. So does git-rebase. > Squash is "Remove all commits from C_newest to C_oldest, and create a new commit using C_newest tree". Rebases just run another git action for every commit in a sequence, e.g. cherry-pick. Rebasing is constructing a set of operations: - construct a set of commits to pick as the commits between (the merge-base of HEAD and the selected commit) and the selected commit - git checkout the --onto HEAD - cherry-pick the selected commits An interactive rebase lets you drop commits, add commits, edit, reword, or fixup/squash commits. Squashing a commit is essentially doing `git cherry-pick --no-commit` of the to-be-squashed commit and then `git commit --amend` to replace the HEAD commit with a new commit that includes the changes staged by `git cherry-pick --no-commit`. Yes, it really is this simple. I aver that it is easier to understand the above than to think of merging and rebasing and cherry-picking as fundamentally different operations.

by tux3 5y ago

arghwhat 5y ago

With cherry-picks (and thus rebase), you ask git to turn a commit into a patch, so it does just that. I would mostly consider auto merges (which I guess are bolted on) as the main area where git itself uses diffs during resolution and even then only as a suggested resolution (you get warned and need to confirm it when validating the merge). So no, it's blobs all the way down. Darcs and Pijul are patch based though.

tux3 5y ago
It's true that git is blob based, as opposed to patch based, but it's not the full picture! In practice, git stores a lot more diffs (or rather, deltas) than it stores loose blobs. (And you probably know this already, but I feel it's still worth making explicit) This is necessary, because when a repo accumulates commits, it becomes a lot more efficient to store most of the objects as deltas instead of separate blobs. If Git didn't do this, it would have a lot of copies, and they would take a lot of space. So the fundamental model of git is truly based on blobs in theory, but in practice many or most git commands will operate on packfiles, and if you look in your .git object store, most likely you will have a few big packfiles containing most objects, and then a much smaller collection of loose blobs. All those diffs are what the "resolving deltas" progress indicator that people see when they do a big clone, fetch, or checkout is about =)
- ori_b 5y ago
  > In practice, git stores a lot more diffs (or rather, deltas) than it stores loose blobs. The diffs it stores are not the diffs you see in git diff. They're rolling checksum based chunks. The data that the delta is computed against is picked with a heuristic ("sort by name and date, try the top 10, and use the smallest result"). And, in practice, the heuristic diffs the older files against the newer ones, rather than diffing in chronological order, so that getting recent data doesn't involve a lot of delta application. The git deltification is better thought of as a compression method than as diffing.
- arghwhat 5y ago
  Packfiles and deltas are a storage and transfer optimization for blobs. Any access to them store and yield blobs. It is for all intents and purposes just an internal serialization format, akin to how a filesystem is just a serialization format that makes all your data one large stream. One generally talks about the provided interface (files for a filesystem, blobs for git) rather than where the bits actually go. Compression algorithms are also to some extend diffs as they serialize to a sequence of "repeat previous segment and add this new data" commands, but it is not useful to consider them as such.
cryptonector 5y ago
Merges, rebases, cherry-picks, are all the same kind of thing. A merge is essentially a rebase that squashes all the commits being picked.
- arghwhat 5y ago
  No, a merge works very differently. A merge is a commit with two parent commits, pointing to a new tree that contains the blobs from both parents. It does not modify any blobs, nor does it modify the parent commits. The full history of all activity is retained. A merge conflict is a case where both trees changed the same blob since their common ancestor. In this case, you have to make a new blob yourself (the "resolution") for use in the merge commit's tree, instead of using one of the parent blobs. Squash is "Remove all commits from C_newest to C_oldest, and create a new commit using C_newest tree". Rebases just run another git action for every commit in a sequence, e.g. cherry-pick.
  - cryptonector 5y ago
    > A merge is a commit with two parent commits, pointing to a new tree that contains the blobs from both parents. The second parent is metadata. The way a merge works is essentially to compute the commits you need to cherry-pick, then cherry-pick them without committing, resolving conflicts in pretty much the same way git cherry-pick does, THEN commit with two parents. > It does not modify any blobs, nor does it modify the parent commits. The full history of all activity is retained. A new commit containing merged content is created, as well as a merge commit with the second parent that documents that a merge happened and what was merged. > A merge conflict is a case where both trees changed the same blob since their common ancestor. In this case, you have to make a new blob yourself (the "resolution") for use in the merge commit's tree, instead of using one of the parent blobs. git merge does the same thing for automatic (and manual) conflict resolution as git cherry-pick. So does git-rebase. > Squash is "Remove all commits from C_newest to C_oldest, and create a new commit using C_newest tree". Rebases just run another git action for every commit in a sequence, e.g. cherry-pick. Rebasing is constructing a set of operations: - construct a set of commits to pick as the commits between (the merge-base of HEAD and the selected commit) and the selected commit - git checkout the --onto HEAD - cherry-pick the selected commits An interactive rebase lets you drop commits, add commits, edit, reword, or fixup/squash commits. Squashing a commit is essentially doing `git cherry-pick --no-commit` of the to-be-squashed commit and then `git commit --amend` to replace the HEAD commit with a new commit that includes the changes staged by `git cherry-pick --no-commit`. Yes, it really is this simple. I aver that it is easier to understand the above than to think of merging and rebasing and cherry-picking as fundamentally different operations.