Email or username:

Password:

Forgot your password?
Julia's posts Post Back to profile
Julia Evans
16 comments
Feoh

@b0rk Wow I wouldn't think "snapshot" would get so much traction :)

Maybe it's a signpost to where you are in your journey towards #git mastery? :)

Thank you for doing what you do as always!

5 January at 20:32 | Open on oldbytes.space
Paul Hoffman

@b0rk Yes to each of those, depending on the type of project (documentation vs. small programming vs. big programming, the number or other contributors (0 vs. 1 vs. 2+), and the git skill level of the other contributors.

5 January at 20:34 | Open on mastodon.social
SnoopJ

@b0rk nice summary!

Aside: have you previously written about the unreasonable effectiveness of "wrong" mental models? I love them and think you used the concept well here.

5 January at 20:41 | Open on hachyderm.io
Julia Evans
mb21

@SnoopJ @b0rk Agreed, but “wrong model” seems to be a bit of a misnomer. A model is a simplified description/way of thinking about something, so every model is wrong to some degree, otherwise it wouldn’t be useful.

In that way, models are like abstractions, which all are famously leaky.

6 January at 7:37 | Open on hachyderm.io
Erik

@b0rk this looks great! I will read and probably share with peers. Thanks so much.

5 January at 20:50 | Open on fosstodon.org
Marcin Juszkiewicz

@b0rk I do not care how SCM handle commit internally.

For me commit is "a change". It may alter content of file, can move it, can have no files even.

If I export commit then it is still a valid change which someone can take and apply. Nevermind with it be "git am", "patch", "quilt" or other SCM system than I used.

And I like your post. Very detailed and was nice read.

5 January at 20:58 | Open on society.oftrolls.com
Todd Chapman

@b0rk thanks! As I read your writeup I realized the the ability to rewrite git history is probably simple because commits are snapshots and thus reordering, inserting, and removing them should be fast.

5 January at 21:07 | Open on infosec.exchange
Simon Tatham

@b0rk every so often I run into somebody with (I think) a Mercurial background, which gives them the habit of referring to git commits as 'changesets'.

Confusingly, they sometimes do this _even_ in circumstances where they clearly are thinking of the associated source snapshot and not the, well, set of changes. "What changeset did you reproduce this bug with?"

5 January at 21:12 | Open on hachyderm.io
Waleed Khan

@b0rk I ran a survey (n = 5) when investigating new terminology for jj: docs.google.com/document/d/1qr

I got similar results: a 50/50 split for diffs vs snapshots. I was more interested to find that people are largely unified about a "revision" being a snapshot.

I think the framing of mental models as "wrong" could be improved ("all models are wrong, but some are useful"). Let's say models are "robust" or not instead. Gravity as a force instead of warping spacetime is a highly robust mental model, even though relativity explains more phenomena. Indeed, we consciously *choose* to model problems using gravity as a force, even though we know that it's technically wrong. This is a characteristic of a robust mental model.

Commits as diffs (or snapshots) is a robust mental model. It explains a great deal of the phenomena that one encounters. Indeed, the underlying implementation could be switched from snapshots to diffs with little user impact. Thus, we can confidently say that it's a robust mental model.

In contrast, branches as "containers" of commits is much less robust. You get problems quickly when two branches point to the same commit, or you rebase a branch without its descendant branches. Thus, this model is much less robust.

I recall in chemistry class learning several different models to explain the same phenomenon (such as for acids/bases). Perhaps we should reject "commits as snapshots" as the ultimate explanation for beginners, and instead teach both, for the same reasons that we teach multiple mental models in other disciplines.

@b0rk I ran a survey (n = 5) when investigating new terminology for jj: docs.google.com/document/d/1qr

I got similar results: a 50/50 split for diffs vs snapshots. I was more interested to find that people are largely unified about a "revision" being a snapshot.

5 January at 21:42 | Open on types.pl
Julia Evans

@arxanas the point about a "revision" being a snapshot is really good, I've noticed that too. might add that

5 January at 21:48 | Open on social.jvns.ca
P-Y

@b0rk Isn't the "wrong mental model for git" pretty much how SVN worked? Or maybe that was my own wrong mental model for SVN.

5 January at 22:54 | Open on androiddev.social
Julia Evans

@py maybe! I never used SVN and I don’t know how it worked

5 January at 23:23 | Open on social.jvns.ca
Kim Gräsman

@b0rk Thanks, I liked that! This post woke something in me re the discussion on rebase vs merge the other day. I think I prefer rebase/linear history because it maps very well to a sequence of patch files that could be copied around and applied independent of git itself. Not sure why that feels so "pure" to me, but it does.

5 January at 22:59 | Open on discuss.systems
Paul Wouters
Richard Levitte

@b0rk
Really nice blog, and yeah, confirmed, there's a stark difference between the mental model (I'm one of the "all of the above" folks) and the actual technical model.

Speaking of this, before git, I worked a lot with monotone, which has quite a lot of similarities to git... however, storage wasn't one of them. Monotone stored commits as diffs, so there were situations where they had to be replayed en masse. That could be quite a performance hit...

6 January at 9:55 | Open on mastodon.nu
Go Up