2 ms·

> things like cherry-picking a merge commit wouldn't make any sense, while they still make perfect sense and are easy to explain with the "commit is a snapshot"

by tomn 3y ago

> things like cherry-picking a merge commit wouldn't make any sense, while they still make perfect sense and are easy to explain with the "commit is a snapshot" mental model IMO it makes just as much sense either way. When cherry-picking a merge commit you have to specify which parent to diff against, which could just as easily be explained in terms of diffs (i.e. which part of an n-way diff to apply). > it's easy to develop a wrong mental model of the repository - a model that most people operate on, but which will bite you sooner or later. That's exactly why so many people end up being confused with Git This doesn't match my experience (as "that guy that people go to for git help"). Perhaps you have a concrete example. Just to be clear, i'm not advocating for teaching or believing that git works in a way that it doesn't, that would be silly. More that being able to think about it in different (equivalent) ways in different situations is helpful.

seba_dos1 3y ago
As also "that guy that people go to for git help", I've seen people clearly surprised that: - cherry-pick creates "duplicated" commits - you can checkout a commit, rather than a branch - two commits in the same repo may be topologically unrelated to each other - merge commit can contain changes unrelated to its parents (usually after making some by accident) - you can git reset --soft Those are just the ones that came to my head on a whim (and don't get me started on rebase-heavy workflows). I've had people telling me that it "finally clicked" when made aware that commit is a state rather than a change. Explaining what I just did to "fix" someone's repo is also often easier after a proper "commit as a snapshot" prelude. If people who used Git for years say "oh, that makes much more sense now" after being presented with basic Git concepts, it suggests that their mental model may have been somewhat flawed. Once you internalize that commit is a snapshot, going from that to thinking about diffs between two commits is easy. The other way around is not so obvious - when checking out a commit from complicated topology, it may not be immediately clear how to get from one state to another by "applying diffs" even if it's technically equivalent, so simple operations will end up seeming like undecipherable magic to you simply because they don't fit your mental model very well.
- tomn 3y ago
  I don't see any of those things as working differently in a diff-based SCM, sorry. If those things conflict with someone's model, then that model is more/differently wrong, and not the one that i'm talking about, which is equivalent to how it actually works.
  - seba_dos1 3y ago
    We're talking about models used by novice people to learn and understand Git, not about theoretical equivalency of mathematical graph transformations - the latter is a truism and doesn't bring much to the table, while the former will obviously be more or less flawed for a while until you become more experienced and fill in the gaps. People who may even have no familiarity with graph theory don't gain anything from thinking about commits as diffs in Git. The whole thread started with a notion of "particle-wave duality", which is technically true, but useless in practice when "diff between two arbitrary commits" is one of the simplest operations to think about in terms of graphs of snapshots.

by tomn 3y ago

seba_dos1 3y ago

As also "that guy that people go to for git help", I've seen people clearly surprised that: - cherry-pick creates "duplicated" commits - you can checkout a commit, rather than a branch - two commits in the same repo may be topologically unrelated to each other - merge commit can contain changes unrelated to its parents (usually after making some by accident) - you can git reset --soft Those are just the ones that came to my head on a whim (and don't get me started on rebase-heavy workflows). I've had people telling me that it "finally clicked" when made aware that commit is a state rather than a change. Explaining what I just did to "fix" someone's repo is also often easier after a proper "commit as a snapshot" prelude. If people who used Git for years say "oh, that makes much more sense now" after being presented with basic Git concepts, it suggests that their mental model may have been somewhat flawed. Once you internalize that commit is a snapshot, going from that to thinking about diffs between two commits is easy. The other way around is not so obvious - when checking out a commit from complicated topology, it may not be immediately clear how to get from one state to another by "applying diffs" even if it's technically equivalent, so simple operations will end up seeming like undecipherable magic to you simply because they don't fit your mental model very well.

tomn 3y ago
I don't see any of those things as working differently in a diff-based SCM, sorry. If those things conflict with someone's model, then that model is more/differently wrong, and not the one that i'm talking about, which is equivalent to how it actually works.
- seba_dos1 3y ago
  We're talking about models used by novice people to learn and understand Git, not about theoretical equivalency of mathematical graph transformations - the latter is a truism and doesn't bring much to the table, while the former will obviously be more or less flawed for a while until you become more experienced and fill in the gaps. People who may even have no familiarity with graph theory don't gain anything from thinking about commits as diffs in Git. The whole thread started with a notion of "particle-wave duality", which is technically true, but useless in practice when "diff between two arbitrary commits" is one of the simplest operations to think about in terms of graphs of snapshots.