5 ms·

Why have so many people written long thoughtful explanations about how the author is wrong to suggest snapshots are a better mental model, and that you think al

Why have so many people written long thoughtful explanations about how the author is wrong to suggest snapshots are a better mental model, and that you think all abstractions are leaky, but you find diffs a better mental model? The entire article is literally about how commits are literally snapshots. I would say people didn't read TFA, but a lot of people are quoting lines from TFA and then going on to argue with/expand on them in a way that is directly contradicted by the next few lines. I think it's because most of the people here have spent years working with git, and are so deeply attached to their understanding that they didn't hear most of what the article said. (Some commentators have pointed out specific oversimplifications the author makes like glossing over pack files, I'm referring to the people who say a git blob is a diff when the entire point of TFA is that it isn't)

nightpool 6y ago
> Why have so many people written long thoughtful explanations about how the author is wrong to suggest snapshots are a better mental model, and that you think all abstractions are leaky, but you find diffs a better mental model? Probably because, to take their words at face value, they find diffs a better mental model? I think impugning "people [...] are so deeply attached to their understanding that they didn't hear most of what the article said" is a real bad faith reading, especially when you even acknowledge that central to people's arguments is "all mental models are leaky". This article may be technically correct about the way git internals are structured, but it makes cherry-pick and rebase more mentally complex for users to understand (you first have to go from commit => patch), not less. Saying "Commits are collections of files + a parent commit, but you can diff it to generate a patch" and saying "Commits are a patch + a parent commit, and you can apply it to generate a collection of files" are isomorphic mental models—the fact that #1 is "correct" (for some value of correct that doesn't include the actual files stored on disk) is really besides the point.
- iudqnolq 6y ago
  My point is that people criticizing TFA's proposed mental model are missing the fact that TFA doesn't propose a mental model, it explains how things work. Both have value, but they're distinct.
  - nightpool 6y ago
    I disagree. TFA is explaining the mental model Git uses to structure their codebase. If you're writing code for Git, this is obviously very useful to understand, but if you're just using it, this is only one of several mental models available to you. In this case, I think it's right to say that the distinction the author is attempting to draw is immaterial to those not working on the Git codebase.
    - iudqnolq 6y ago
      If your code is written in a certain way that's a model, not a mental model.
      - iainmerrick 6y ago
        Yes! It just seems so strange not to care about how things actually are in software. Is it a way of coping with the fact that so much software is so deeply layered and complex now? Maybe I’m misremembering, but I feel like I didn’t see this usage of “mental model” much until fairly recently. The first I recall being surprised at was a discussion of a “mental model of Javascript” -- why would you need a mental model of something with a very detailed spec and multiple compatible implementations to study? If you want to understand how some aspect works, just look up how it actually does work.
        Dylan16807 6y ago
        Unless you open up the spec every single time you make a prediction, you're using a mental model. And the spec is probably not arranged for easy use.
        iudqnolq 6y ago
        It's necessary to approximate, but if someone tells you your approximation is wrong it makes no sense to say it's right because you prefer it that way. If your mental model is that floats are real numbers and someone tells you they aren't, you don't go "I philosophically prefer to think they're reals, so you're wrong". You either update your mental model or decide you'd rather be a bit wrong than learn something (you perceive as) tedious.
smallnamespace 6y ago
People are disagreeing with the author, not because they didn't necessarily read the article, but because they don't agree about how things should be defined. At the root, this is a disagreement about semantics and philosophy, not about git itself. I'm going to refer to Aristotle here: we think we have knowledge of a thing only when we have grasped its cause, and there are four general 'causes' [1]: - The material cause: 'What is it made of?' - The formal cause: 'What is the ideal of this thing?' , e.g. what's its abstract nature? - The efficient cause: 'How did this thing come to be?' - The final cause: 'What is its purpose?' How is it actually used? What role does it play in the world? Here we can see that commits are used (at least in the git internals) as 'snapshots' — they refer to bytes, not changes in bytes. That's pretty close to the formal and efficient causes — the abstraction inside of git is closest to a snapshot, and that comes from the history of what Linus wanted when he wrote it. But! The underlying storage uses deltas (which are diffs) to save space. That's the material cause. But also, when we actually use commits, git often creates diffs for us as a convenience (cherry-picking, rebasing), and hides the fact that they're snapshots under the hood (final cause). So there's an inherent tension between the different ways to answer 'what is a thing?'. For commits, this is especially bad, since there's an even split between 'causes'. This tension never goes away because the most useful definition really depends on the context. [1] https://plato.stanford.edu/entries/aristotle-causality/#FouCau https://plato.stanford.edu/entries/aristotle-causality/#FouC...
- iudqnolq 6y ago
  This is exactly what I'm talking about. A person posts "this is literally how this works", and someone replies "philosophically I would prefer to think it works differently, therefore you're wrong".
  - hnjst 6y ago
    Your distilled summary of this form of objection relying on wishful thinking made my day, thanks a lot!
- efaref 6y ago
  The true zen of source control is that they are both.
mekkkkkk 6y ago
What does TFA mean in this context?
- dekerta 6y ago
  TFA = The F**ing Article
  - mekkkkkk 6y ago
    Thanks. I had a hunch. I'm familiar with "RTFM", but would probably get equally confused if "TFM" was used as a noun.
    - hunter2_ 6y ago
      I suspect the chronology is something like RTFM -> TFM -> RTFA -> TFA, but the second and third might be switched. Dropping the R does introduce obscurity, but being able to convey the underlying sentiment (that while the content could/should have been consulted, it seems as though it was not) without a verb allows for a nonconfrontational syntax similar to passive voice, but even moreso, and often without obvious "weasel" effect, to boot!
      - mekkkkkk 6y ago
        Makes a lot of sense, thanks! Maybe it's also useful since the R is read explicitly as "read". Hence "they should instead be RTFM" sounds grammatically wrong. Breaking off the verb allows for a more natural read. It's funny how an abbreviation can carry more information than whatever it's short for.
  - nayuki 6y ago
    And I believe this slang came from Slashdot, which is like the Hacker News forum in the decade before Hacker News
    - Agingcoder 6y ago
      Interesting, I didn't know it came from Slashdot! I spent quite a bit of time reading it in the early 2000s, and sometimes miss the subculture and not always subtle jokes (beowulf clusters... ). The moderation system encouraged jokes (there was a specific 'funny' tag), unlike HN which does not 'orient' things, and happens to be very serious.
koolba 6y ago
> Why have so many people written long thoughtful explanations about how the author is wrong to suggest snapshots are a better mental model, and that you think all abstractions are leaky, but you find diffs a better mental model? Once you remember (learn?) that a commit can have N parents, it becomes apparent that it cannot be a single diff.
Agingcoder 6y ago
Agreed, commits are snapshots, whether we like or not. For obvious storage efficiency reasons, the implementation then diffs/packs/etc, but this is a different issue altogether. I have found that I can't work with git with a different mental model (diffs). Every time things get messy, the diff model is not enough, whereas snapshots + commit graph + names/pointers make things natural. Interestingly enough, when migrating people from svn to git, explaining the actual model makes the transition much smoother, so it would seem I'm not the only one.
happyconcepts 6y ago
Can't satisfy everybody.
hongsy 6y ago
i convinced myself that commits are snapshots by doing the following: # generate a 100M text file base64 -b 76 /dev/urandom | head -c 100000000 > file.txt git add . && git commit -m "1" # remove first line and add a new line to bottom tail -n +2 file.txt > tmp && rm file.txt && mv tmp file.txt && base64 -b 76 /dev/urandom | head -n 1 >> file.txt git add . && git commit -m "2" # repeat tail -n +2 file.txt > tmp && rm file.txt && mv tmp file.txt && base64 -b 76 /dev/urandom | head -n 1 >> file.txt git add . && git commit -m "3" ... du -sh . # a very big folder each of the commits are almost 80M big in the git folder. if you run `du -h .` you can see how git stores each object individually (80M big)
da39a3ee 6y ago
I’ve read the article before and it’s entirely unclear how it is supposed to be helpful. As the author acknowledges, things like cherry-pick show that one can think of commits as diffs whereas in the git implementation the object known as a commit is a snapshot of the state of a directory tree. Fine, but so what? Both times I’ve read this article my impression has been that the author is relatively new to git and processing some new information they’ve learned.

nightpool 6y ago

> Why have so many people written long thoughtful explanations about how the author is wrong to suggest snapshots are a better mental model, and that you think all abstractions are leaky, but you find diffs a better mental model? Probably because, to take their words at face value, they find diffs a better mental model? I think impugning "people [...] are so deeply attached to their understanding that they didn't hear most of what the article said" is a real bad faith reading, especially when you even acknowledge that central to people's arguments is "all mental models are leaky". This article may be technically correct about the way git internals are structured, but it makes cherry-pick and rebase more mentally complex for users to understand (you first have to go from commit => patch), not less. Saying "Commits are collections of files + a parent commit, but you can diff it to generate a patch" and saying "Commits are a patch + a parent commit, and you can apply it to generate a collection of files" are isomorphic mental models—the fact that #1 is "correct" (for some value of correct that doesn't include the actual files stored on disk) is really besides the point.

iudqnolq 6y ago
My point is that people criticizing TFA's proposed mental model are missing the fact that TFA doesn't propose a mental model, it explains how things work. Both have value, but they're distinct.
- nightpool 6y ago
  I disagree. TFA is explaining the mental model Git uses to structure their codebase. If you're writing code for Git, this is obviously very useful to understand, but if you're just using it, this is only one of several mental models available to you. In this case, I think it's right to say that the distinction the author is attempting to draw is immaterial to those not working on the Git codebase.
  - iudqnolq 6y ago
    If your code is written in a certain way that's a model, not a mental model.
    - iainmerrick 6y ago
      Yes! It just seems so strange not to care about how things actually are in software. Is it a way of coping with the fact that so much software is so deeply layered and complex now? Maybe I’m misremembering, but I feel like I didn’t see this usage of “mental model” much until fairly recently. The first I recall being surprised at was a discussion of a “mental model of Javascript” -- why would you need a mental model of something with a very detailed spec and multiple compatible implementations to study? If you want to understand how some aspect works, just look up how it actually does work.
      - Dylan16807 6y ago
        Unless you open up the spec every single time you make a prediction, you're using a mental model. And the spec is probably not arranged for easy use.
        iudqnolq 6y ago
        It's necessary to approximate, but if someone tells you your approximation is wrong it makes no sense to say it's right because you prefer it that way. If your mental model is that floats are real numbers and someone tells you they aren't, you don't go "I philosophically prefer to think they're reals, so you're wrong". You either update your mental model or decide you'd rather be a bit wrong than learn something (you perceive as) tedious.

smallnamespace 6y ago

People are disagreeing with the author, not because they didn't necessarily read the article, but because they don't agree about how things should be defined. At the root, this is a disagreement about semantics and philosophy, not about git itself. I'm going to refer to Aristotle here: we think we have knowledge of a thing only when we have grasped its cause, and there are four general 'causes' [1]: - The material cause: 'What is it made of?' - The formal cause: 'What is the ideal of this thing?' , e.g. what's its abstract nature? - The efficient cause: 'How did this thing come to be?' - The final cause: 'What is its purpose?' How is it actually used? What role does it play in the world? Here we can see that commits are used (at least in the git internals) as 'snapshots' — they refer to bytes, not changes in bytes. That's pretty close to the formal and efficient causes — the abstraction inside of git is closest to a snapshot, and that comes from the history of what Linus wanted when he wrote it. But! The underlying storage uses deltas (which are diffs) to save space. That's the material cause. But also, when we actually use commits, git often creates diffs for us as a convenience (cherry-picking, rebasing), and hides the fact that they're snapshots under the hood (final cause). So there's an inherent tension between the different ways to answer 'what is a thing?'. For commits, this is especially bad, since there's an even split between 'causes'. This tension never goes away because the most useful definition really depends on the context. [1] https://plato.stanford.edu/entries/aristotle-causality/#FouCau https://plato.stanford.edu/entries/aristotle-causality/#FouC...

iudqnolq 6y ago
This is exactly what I'm talking about. A person posts "this is literally how this works", and someone replies "philosophically I would prefer to think it works differently, therefore you're wrong".
- hnjst 6y ago
  Your distilled summary of this form of objection relying on wishful thinking made my day, thanks a lot!
efaref 6y ago
The true zen of source control is that they are both.

mekkkkkk 6y ago

What does TFA mean in this context?

dekerta 6y ago
TFA = The F**ing Article
- mekkkkkk 6y ago
  Thanks. I had a hunch. I'm familiar with "RTFM", but would probably get equally confused if "TFM" was used as a noun.
  - hunter2_ 6y ago
    I suspect the chronology is something like RTFM -> TFM -> RTFA -> TFA, but the second and third might be switched. Dropping the R does introduce obscurity, but being able to convey the underlying sentiment (that while the content could/should have been consulted, it seems as though it was not) without a verb allows for a nonconfrontational syntax similar to passive voice, but even moreso, and often without obvious "weasel" effect, to boot!
    - mekkkkkk 6y ago
      Makes a lot of sense, thanks! Maybe it's also useful since the R is read explicitly as "read". Hence "they should instead be RTFM" sounds grammatically wrong. Breaking off the verb allows for a more natural read. It's funny how an abbreviation can carry more information than whatever it's short for.
- nayuki 6y ago
  And I believe this slang came from Slashdot, which is like the Hacker News forum in the decade before Hacker News
  - Agingcoder 6y ago
    Interesting, I didn't know it came from Slashdot! I spent quite a bit of time reading it in the early 2000s, and sometimes miss the subculture and not always subtle jokes (beowulf clusters... ). The moderation system encouraged jokes (there was a specific 'funny' tag), unlike HN which does not 'orient' things, and happens to be very serious.

koolba 6y ago

> Why have so many people written long thoughtful explanations about how the author is wrong to suggest snapshots are a better mental model, and that you think all abstractions are leaky, but you find diffs a better mental model? Once you remember (learn?) that a commit can have N parents, it becomes apparent that it cannot be a single diff.

Agingcoder 6y ago

Agreed, commits are snapshots, whether we like or not. For obvious storage efficiency reasons, the implementation then diffs/packs/etc, but this is a different issue altogether. I have found that I can't work with git with a different mental model (diffs). Every time things get messy, the diff model is not enough, whereas snapshots + commit graph + names/pointers make things natural. Interestingly enough, when migrating people from svn to git, explaining the actual model makes the transition much smoother, so it would seem I'm not the only one.

happyconcepts 6y ago

Can't satisfy everybody.

hongsy 6y ago

i convinced myself that commits are snapshots by doing the following: # generate a 100M text file base64 -b 76 /dev/urandom | head -c 100000000 > file.txt git add . && git commit -m "1" # remove first line and add a new line to bottom tail -n +2 file.txt > tmp && rm file.txt && mv tmp file.txt && base64 -b 76 /dev/urandom | head -n 1 >> file.txt git add . && git commit -m "2" # repeat tail -n +2 file.txt > tmp && rm file.txt && mv tmp file.txt && base64 -b 76 /dev/urandom | head -n 1 >> file.txt git add . && git commit -m "3" ... du -sh . # a very big folder each of the commits are almost 80M big in the git folder. if you run `du -h .` you can see how git stores each object individually (80M big)

da39a3ee 6y ago

I’ve read the article before and it’s entirely unclear how it is supposed to be helpful. As the author acknowledges, things like cherry-pick show that one can think of commits as diffs whereas in the git implementation the object known as a commit is a snapshot of the state of a directory tree. Fine, but so what? Both times I’ve read this article my impression has been that the author is relatively new to git and processing some new information they’ve learned.