I think merge commits are key to why "snapshots" are a better model than "diffs", and a stronger arguments would emphasize this more.
Like people have said, the two models:
- a commits is a snapshot plus a pointer to a parent commit
- a commits is a pointer to a parent commit plus a diff
are sort of isomorphic. And some commands in the git porcelain (like git cherry-pick, or git rebase) indeed make more sense if you think of commits as diffs.
But this isomorphism becomes really strained when you have commits with more than one parent (or even zero parents). (And I think it's telling that those commands don't play very nicely with merge commits or the root commit.)
If you really want to incorporate merge commits and the root commit, the alternatives become:
- a commit is a snapshot, together with a list of zero or more pointers to parent commits
- a commit is a list of M >= 0 pointers to parent commits, together with N > 0 diffs, subject to the invariant that:
a) M = N, except that for exactly one commit, which we will call the "root" we are allowed to have M = 0 but N = 1
b) starting from any commit, if you traverse a path back to the root commit by following parent pointers, and then sequentially (in reverse order) apply, for each commit in the path, the diff that corresponds to the parent pointer chosen, then the result of composing all those diffs is independent of the path chosen.
And when you put it like that, it's pretty clear that the "diffs" model is really impractical, and that's why it's a lot better to think of commits as snapshots.
I agree that things like "Go To Definition" can be pretty bad (especially when a codebase has code that is auto-generated, but you haven't figured out how yet).
But I'm curious, what benefits do you see in your approach over just doing a grep in the folder (or e.g. Ctrl+Shift+F "Find in Files" in Pycharm)?
I think first link really oversells the study it references, though.Key quotes, from the paper:
"The factor by which β was reduced was conservatively set to 2."
"Varying degrees of mask effectiveness are modelled by the mask transmission rate T and mask absorption rate A, which denote the proportion of viruses that are stopped by the mask during exhaling (transmission) versus inhaling (absorption), respectively. Weset T = 0.7 and A = 0.7 to model the use of inexpensive, widely available, and even nonmedical or homemade masks [...]"
So basically, they assume certain values for how effective masks are, and then simulates the dynamics of the epidemic. Nowhere do they try to justify the specific values chosen.
I expect that the conclusions cited (if only 40% wear masks, there is little benefit; if 80% wear masks, total cases go down by a factor 1/12) to be heavily dependent on those assumptions, and so I would be cautious to read too much into it.
Like people have said, the two models:
- a commits is a snapshot plus a pointer to a parent commit
- a commits is a pointer to a parent commit plus a diff
are sort of isomorphic. And some commands in the git porcelain (like git cherry-pick, or git rebase) indeed make more sense if you think of commits as diffs.
But this isomorphism becomes really strained when you have commits with more than one parent (or even zero parents). (And I think it's telling that those commands don't play very nicely with merge commits or the root commit.)
If you really want to incorporate merge commits and the root commit, the alternatives become:
- a commit is a snapshot, together with a list of zero or more pointers to parent commits
- a commit is a list of M >= 0 pointers to parent commits, together with N > 0 diffs, subject to the invariant that:
a) M = N, except that for exactly one commit, which we will call the "root" we are allowed to have M = 0 but N = 1
b) starting from any commit, if you traverse a path back to the root commit by following parent pointers, and then sequentially (in reverse order) apply, for each commit in the path, the diff that corresponds to the parent pointer chosen, then the result of composing all those diffs is independent of the path chosen.
And when you put it like that, it's pretty clear that the "diffs" model is really impractical, and that's why it's a lot better to think of commits as snapshots.