4 ms·

From a user point of view, you should not see commits as diffs or deltas, but as a full snapshots of the contents of the repository. Delta compression is just

From a user point of view, you should not see commits as diffs or deltas, but as a full snapshots of the contents of the repository. Delta compression is just an implementation detail for storage optimization. Conceptually each commit is an immutable snapshot in its own right.

cryptonector 4y ago
> From a user point of view, you should not see commits as diffs or deltas, but as a full snapshots of the contents of the repository. That tends to lead to a merge-centric workflow. The alternative makes it easy to understand rebase. Ergo it's good.
- stu2b50 4y ago
  I don't see any particular reason that'd be the case. Even with rebase, the diff model causes some of git's behavior to no longer make sense. For instance, the fact that rebase causes an entirely new series of commits to be made - this is because rebase is just a layer over cherry-picking commits, and that cherry-picking commits calculates the diffs between two commits then applies the diff as its own, new commit. If commits were diffs, then that process doesn't make any sense. It only makes sense when you think of commits as snapshots, and cherry-pick ing as taking a commit, calculating the diff with the current commit, and then applying that diff to make a brand new commit.
  - cryptonector 4y ago
    Yes, rebase is a series of cherry-picks. Each commit picked is treated as a set of diffs that are applied with conflict resolution, then committed, then off to the next. The mental model of commits as diffs works, obviously. > If commits were diffs, then that process doesn't make any sense. It only makes sense when you think of commits as snapshots, and cherry-pick ing as taking a commit, calculating the diff with the current commit, and then applying that diff to make a brand new commit. Sure it does. It works for me. You can use whatever mental model of Git that you works for you.

cryptonector 4y ago

> From a user point of view, you should not see commits as diffs or deltas, but as a full snapshots of the contents of the repository. That tends to lead to a merge-centric workflow. The alternative makes it easy to understand rebase. Ergo it's good.

stu2b50 4y ago
I don't see any particular reason that'd be the case. Even with rebase, the diff model causes some of git's behavior to no longer make sense. For instance, the fact that rebase causes an entirely new series of commits to be made - this is because rebase is just a layer over cherry-picking commits, and that cherry-picking commits calculates the diffs between two commits then applies the diff as its own, new commit. If commits were diffs, then that process doesn't make any sense. It only makes sense when you think of commits as snapshots, and cherry-pick ing as taking a commit, calculating the diff with the current commit, and then applying that diff to make a brand new commit.
- cryptonector 4y ago
  Yes, rebase is a series of cherry-picks. Each commit picked is treated as a set of diffs that are applied with conflict resolution, then committed, then off to the next. The mental model of commits as diffs works, obviously. > If commits were diffs, then that process doesn't make any sense. It only makes sense when you think of commits as snapshots, and cherry-pick ing as taking a commit, calculating the diff with the current commit, and then applying that diff to make a brand new commit. Sure it does. It works for me. You can use whatever mental model of Git that you works for you.