On Mon, Oct 6, 2025, at 21:36, Julia Evans wrote:

[snip]

quoted

quoted

+blobs::
+    A blob is how Git represents a file. A blob object contains the
+    file's contents.
++
+Storing a new blob for every new version of a file can get big, so
+`git gc` periodically compresses objects for efficiency in
`.git/objects/pack`.

This gets into mentioning implementation files(?) like you mentioned in
the commit message.

That's true! The reason I think this is important to mention is that I find
that people often "reject" information that they find implausible, even
if it comes from a credible source. ("that can't be true! I must be
not understanding correctly. Oh well, I'll just ignore that!")

I sometimes hear from users that "commits can't be snapshots", because
it would take up too much disk space to store every version of
every commit. So I find that sometimes explaining a little bit about the
implementation can make the information more memorable.

Certainly I'm not able to remember details that don't make sense
with my mental model of how computers work and I don't expect other
people to either, so I think it's important to give an explanation that
handles the biggest "objections".

That’s very intresting. Yes, maybe people need to be told/taught to a
level which might be considered “just implementation details” or else
both neither their curiosity won’t be satisfied *nor* will their own
sense of error-correction for the seemingly implausible.

[snip]

quoted

I appreciate that this is the first version and you might have plans
after this one. But I wonder if this doc could use a fair number of
`gitlink` to branch out to all the other parts. Like git-reflog(1),
gitglossary(7).

That's reasonable. Do you often use the "See also" section of
man pages? I've never looked at them so I'm always curious about
how people are actually using them in practice.

I don’t really use See Also when looking things up. But I notice all the
mentions of other docs in running text.

[snip]