3 ms·

This is a good mental model. The internals are the internals. But the model users see is that a repository is a bag of commits (deltas) that organize into a t

This is a good mental model. The internals are the internals. But the model users see is that a repository is a bag of commits (deltas) that organize into a tree, with branches and tags being names for specific commits. With this model in mind anyone can become a Git power user.

stu2b50 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. 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.
josephg 4y ago
> But the model users see is that a repository is a bag of commits (deltas) Commits in your .git directory aren’t stored using deltas from a previous commit. Each different version of every file is stored in full.
- MaxBarraclough 4y ago
  From https://git-scm.com/book/en/v2/Git-Internals-Packfiles https://git-scm.com/book/en/v2/Git-Internals-Packfiles : > You have two nearly identical 22K objects on your disk (each compressed to approximately 7K). Wouldn’t it be nice if Git could store one of them in full but then the second object only as the delta between it and the first? > It turns out that it can. The initial format in which Git saves objects on disk is called a “loose” object format. However, occasionally Git packs up several of these objects into a single binary file called a “packfile” in order to save space and be more efficient. ... > What is also interesting is that the second version of the file is the one that is stored intact, whereas the original version is stored as a delta — this is because you’re most likely to need faster access to the most recent version of the file.
  - masklinn 4y ago
    That is what's covered by the article, but as various commenters have noted it's not part of git's model, it's an optimisation of git's storage. So thinking in those terms for modelling / visualising git's behaviour is nonsensical.
    - MaxBarraclough 4y ago
      It's not hard to make correct statements about the git user interface without being misleading about its internals. josephg said: > Each different version of every file is stored in full. which is an untrue statement about how git internally manages its data. It would be fine had they instead said: > From the user's point of view, it's as if each different version of every file is stored in full. Internally, git may perform compression, including differential compression. This isn't the first time I've seen this confusion. This 2014 StackOverflow thread [0] does the same, as does an old HN thread. [1] The solution is clear communication. [0] https://stackoverflow.com/q/8198105/ https://stackoverflow.com/q/8198105/ [1] https://news.ycombinator.com/item?id=25459757 https://news.ycombinator.com/item?id=25459757
juped 4y ago
There are two ways commits can be treated in Git. Most of the time, a commit is a specific tree and some metadata. There are, however, some rebase-like operations that use the commit metadata to treat a commit as a diff against one or more parents which it points to. You're wrong in this discussion because it's about storage, but you do need to flip into this dual view of the commit graph to use rebase-like operations correctly.
- cryptonector 4y ago
  Exactly. Thinking of commits as diffs helps think about rebasing.

stu2b50 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. 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.

josephg 4y ago

> But the model users see is that a repository is a bag of commits (deltas) Commits in your .git directory aren’t stored using deltas from a previous commit. Each different version of every file is stored in full.

MaxBarraclough 4y ago
From https://git-scm.com/book/en/v2/Git-Internals-Packfiles https://git-scm.com/book/en/v2/Git-Internals-Packfiles : > You have two nearly identical 22K objects on your disk (each compressed to approximately 7K). Wouldn’t it be nice if Git could store one of them in full but then the second object only as the delta between it and the first? > It turns out that it can. The initial format in which Git saves objects on disk is called a “loose” object format. However, occasionally Git packs up several of these objects into a single binary file called a “packfile” in order to save space and be more efficient. ... > What is also interesting is that the second version of the file is the one that is stored intact, whereas the original version is stored as a delta — this is because you’re most likely to need faster access to the most recent version of the file.
- masklinn 4y ago
  That is what's covered by the article, but as various commenters have noted it's not part of git's model, it's an optimisation of git's storage. So thinking in those terms for modelling / visualising git's behaviour is nonsensical.
  - MaxBarraclough 4y ago
    It's not hard to make correct statements about the git user interface without being misleading about its internals. josephg said: > Each different version of every file is stored in full. which is an untrue statement about how git internally manages its data. It would be fine had they instead said: > From the user's point of view, it's as if each different version of every file is stored in full. Internally, git may perform compression, including differential compression. This isn't the first time I've seen this confusion. This 2014 StackOverflow thread [0] does the same, as does an old HN thread. [1] The solution is clear communication. [0] https://stackoverflow.com/q/8198105/ https://stackoverflow.com/q/8198105/ [1] https://news.ycombinator.com/item?id=25459757 https://news.ycombinator.com/item?id=25459757

juped 4y ago

There are two ways commits can be treated in Git. Most of the time, a commit is a specific tree and some metadata. There are, however, some rebase-like operations that use the commit metadata to treat a commit as a diff against one or more parents which it points to. You're wrong in this discussion because it's about storage, but you do need to flip into this dual view of the commit graph to use rebase-like operations correctly.

cryptonector 4y ago
Exactly. Thinking of commits as diffs helps think about rebasing.