From: "Julia Evans" <julia@jvns•ca>
To: "Junio C Hamano" <gitster@pobox•com>, "Patrick Steinhardt" <ps@pks•im>
Cc: "Julia Evans" <gitgitgadget@gmail•com>, git@vger•kernel.org
Subject: Re: [PATCH] doc: add a explanation of Git's data model
Date: Wed, 08 Oct 2025 15:06:29 -0400 [thread overview]
Message-ID: <395232da-4ac6-4311-ae44-2bbf92fa6d2f@app.fastmail.com> (raw)
In-Reply-To: <xmqqecrdgzk8.fsf@gitster.g>
On Wed, Oct 8, 2025, at 11:53 AM, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks•im> writes:
>
>>> 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".
>>
>> Hm, fair I guess. In any case, if we want to mention this I'd leave away
>> the details how exactly Git achieves this. E.g. we could say something
>> like:
>>
>> Storing a new blob for every new version of a file can result to a
>> lot of duplication. Git regularly runs repository maintenance to
>> optimize to counteract this. Part of the maintenance involves
>> compression of objects, where incremental changes to the same object
>> are optimized to be stored as deltas, only.
>>
>> We skip over the details, but this should give enough pointers to an
>> interested reader to go dig deeper. We could also generalize this to
>> objects in general, not only blobs.
>
> Interesting. It is of course not wrong at all, but it was not what
> I would have expected for the first explanation to help confused
> folks who say "commits cannot be snapshots as they take too much
> space".
>
> To me, it was a realization that even in a project whose tree (think
> of "du -s .") is huge, each of its commits touches only a handful
> of paths, hence a large portion of that huge tree would be shared
> with the previous snapshot.
That's a good point, I forgot that I've explained it that way too.
I might change it to that instead.
>>> > This misses "refs/remotes/<remote>/HEAD". This reference is a symbolic
>>> > reference that indicates the default branch on the remote side.
>>>
>>> Is "refs/remotes/<remote>/HEAD" a remote-tracking branch?
>>> I've never thought about that reference and I'm not sure what to call it.
>>
>> No, it's not. I think the term we use is "remote reference".
>
> Honestly I didn't know/think we have any special terminology for the
> refs/remotes/*/HEAD symref.
>
> Historically HEAD did not "track" the remote state, and we did take
> advantage of that fact to use it as a place to record the preference
> with respect to which remote-tracking branch we would want to
> primarily interact with.
>
> But these days because the protocol is capable of expressing where
> the symrefs point at, the users can make it track just like all
> other refs inside refs/remotes/*/ hiearchy. So I personally think
> it is OK to call it in remote-tracking branch.
I may just add this to the remote-tracking branch sentence then,
which is hopefully correct:
`refs/remotes/<remote>/HEAD` is a symbolic reference to the remote's
default branch. This is the branch that `git clone` checks out by default.
next prev parent reply other threads:[~2025-10-08 19:06 UTC|newest]
Thread overview: 89+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-03 17:34 [PATCH] doc: add a explanation of Git's data model Julia Evans via GitGitGadget
2025-10-03 21:46 ` Kristoffer Haugsbakk
2025-10-06 19:36 ` Julia Evans
2025-10-06 21:44 ` D. Ben Knoble
2025-10-06 21:46 ` Julia Evans
2025-10-06 21:55 ` D. Ben Knoble
2025-10-09 13:20 ` Julia Evans
2025-10-08 9:59 ` Kristoffer Haugsbakk
2025-10-06 3:32 ` Junio C Hamano
2025-10-06 19:03 ` Julia Evans
2025-10-07 12:37 ` Kristoffer Haugsbakk
2025-10-07 16:38 ` Junio C Hamano
2025-10-07 14:32 ` Patrick Steinhardt
2025-10-07 17:02 ` Junio C Hamano
2025-10-07 19:30 ` Julia Evans
2025-10-07 20:01 ` Junio C Hamano
2025-10-07 18:39 ` D. Ben Knoble
2025-10-07 18:55 ` Julia Evans
2025-10-08 4:18 ` Patrick Steinhardt
2025-10-08 15:53 ` Junio C Hamano
2025-10-08 19:06 ` Julia Evans [this message]
2025-10-08 13:53 ` [PATCH v2] " Julia Evans via GitGitGadget
2025-10-10 11:51 ` Patrick Steinhardt
2025-10-13 14:48 ` Junio C Hamano
2025-10-14 5:45 ` Patrick Steinhardt
2025-10-14 9:18 ` Julia Evans
2025-10-14 11:45 ` Patrick Steinhardt
2025-10-14 13:39 ` Junio C Hamano
2025-10-14 21:12 ` [PATCH v3] " Julia Evans via GitGitGadget
2025-10-15 6:24 ` Patrick Steinhardt
2025-10-15 15:34 ` Junio C Hamano
2025-10-15 17:20 ` Julia Evans
2025-10-15 20:42 ` Junio C Hamano
2025-10-16 14:21 ` Julia Evans
2025-10-15 19:58 ` Junio C Hamano
2025-10-16 15:19 ` Julia Evans
2025-10-16 16:54 ` Junio C Hamano
2025-10-16 18:59 ` Julia Evans
2025-10-16 20:48 ` Junio C Hamano
2025-10-16 15:24 ` Kristoffer Haugsbakk
2025-10-20 16:37 ` Kristoffer Haugsbakk
2025-10-20 18:01 ` Junio C Hamano
2025-10-27 19:32 ` [PATCH v4] doc: add an " Julia Evans via GitGitGadget
2025-10-27 21:54 ` Junio C Hamano
2025-10-28 20:10 ` Julia Evans
2025-10-28 20:31 ` Junio C Hamano
2025-10-30 20:32 ` [PATCH v5] " Julia Evans via GitGitGadget
2025-10-31 14:44 ` Junio C Hamano
2025-11-03 7:40 ` Patrick Steinhardt
2025-11-03 15:38 ` Junio C Hamano
2025-11-03 19:43 ` Julia Evans
2025-11-04 1:34 ` Junio C Hamano
2025-11-04 15:45 ` Julia Evans
2025-11-04 20:53 ` Junio C Hamano
2025-11-04 21:24 ` Julia Evans
2025-11-04 23:45 ` Junio C Hamano
2025-11-05 0:02 ` Julia Evans
2025-11-05 3:21 ` Ben Knoble
2025-11-05 16:26 ` Julia Evans
2025-11-06 3:07 ` Ben Knoble
2025-10-31 21:49 ` Junio C Hamano
2025-11-03 7:40 ` Patrick Steinhardt
2025-11-03 19:52 ` Julia Evans
2025-11-07 19:52 ` [PATCH v6] " Julia Evans via GitGitGadget
2025-11-07 21:03 ` Junio C Hamano
2025-11-07 21:23 ` Junio C Hamano
2025-11-07 21:40 ` Julia Evans
2025-11-07 23:07 ` Junio C Hamano
2025-11-08 19:43 ` Junio C Hamano
2025-11-09 0:48 ` Ben Knoble
2025-11-09 4:59 ` Junio C Hamano
2025-11-10 15:56 ` Julia Evans
2025-11-11 10:13 ` Junio C Hamano
2025-11-11 13:07 ` Ben Knoble
2025-11-11 15:24 ` Julia Evans
2025-11-12 19:16 ` Junio C Hamano
2025-11-12 22:49 ` Junio C Hamano
2025-11-13 19:50 ` Julia Evans
2025-11-13 20:07 ` Junio C Hamano
2025-11-13 20:18 ` Julia Evans
2025-11-13 20:34 ` Chris Torek
2025-11-13 23:11 ` Junio C Hamano
2025-11-12 19:53 ` [PATCH v7] " Julia Evans via GitGitGadget
2025-11-12 20:26 ` Junio C Hamano
2025-11-23 2:37 ` Junio C Hamano
2025-12-01 8:14 ` Patrick Steinhardt
2025-12-02 12:25 ` Junio C Hamano
2025-10-09 14:20 ` [PATCH] doc: add a " Julia Evans
2025-10-10 0:42 ` Ben Knoble
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=395232da-4ac6-4311-ae44-2bbf92fa6d2f@app.fastmail.com \
--to=julia@jvns$(echo .)ca \
--cc=git@vger$(echo .)kernel.org \
--cc=gitgitgadget@gmail$(echo .)com \
--cc=gitster@pobox$(echo .)com \
--cc=ps@pks$(echo .)im \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox