From: "Julia Evans" <julia@jvns•ca>
To: "D. Ben Knoble" <ben.knoble@gmail•com>
Cc: "Junio C Hamano" <gitster@pobox•com>,
"Julia Evans" <gitgitgadget@gmail•com>,
git@vger•kernel.org,
"Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail•com>,
"Patrick Steinhardt" <ps@pks•im>
Subject: Re: [PATCH v5] doc: add an explanation of Git's data model
Date: Wed, 05 Nov 2025 11:26:42 -0500 [thread overview]
Message-ID: <7217ae44-5ad5-468c-b76b-c485247fb2f4@app.fastmail.com> (raw)
In-Reply-To: <7E8706EF-6C15-43AD-A847-5C896D9235AA@gmail.com>
On Tue, Nov 4, 2025, at 10:21 PM, Ben Knoble wrote:
>> Le 4 nov. 2025 à 19:02, Julia Evans <julia@jvns•ca> a écrit :
>>
>>
>>
>>> On Tue, Nov 4, 2025, at 6:45 PM, Junio C Hamano wrote:
>>> "Julia Evans" <julia@jvns•ca> writes:
>>>> I do not see the point of implying that the commit ID is not "special", or that
>>>> it's only one of many ways to find a commit because to me it seems very special,
>>>> since there is no way I know of to retrieve a commit that doesn't ultimately
>>>> end up using the commit ID at some point. (though that ID might not be encoded
>>>> in hexadecimal)
>>> That is not what I am trying to say. The hexadecimal name is the
>>> most neutral way to refer to a commit object, and in that sense it
>>> is special. It is the way ref subsystem uses to record the name of
>>> objects, and that makes it special enough.
>>> But that does not mean that the name _is_ the object. The
>>> hexadecimal name is a way you use to name the object, but is not the
>>> object itself, and the special-ness of that name does not change it.
>>
>> Okay. I still do not understand at all why this is so important to you
>> (for the reasons I mentioned before) but I'll see if there's anything I can do.
>
> Perhaps one way to look at is, what diagram would I draw given
> different textual explanations?
>
> The diagram we _want_ folks to draw (?) is the one where a branch
> points at a commit [a circle, perhaps], which points to a tree
> [triangle] and recursively blobs [squares], like I’ve seen Stolee draw
> for GitHub blogs.
>
> We might also want folks to label the arrows with names, or not.
>
> One way to interpret the “branch refers to a commit ID” might be to
> draw a diagram where the branch points to an ID label, and to find the
> circle you have to separately consult a different part of the diagram.
Yes, the most common type of Git diagram I see is something like this:
https://git-scm.com/book/en/v2/images/head-to-master.png
which only includes references, commits, and HEAD.
That's the diagram I have in mind when writing this text, and I think it's
a useful and accurate diagram to keep in mind, and it's one that you see
very often when using Git tools, including in `git log --graph`. (it's not
a _complete_ diagram of every type of object, but diagrams do not need to be
complete to be accurate)
I personally would not use a graph diagram to explain how commits relate to
trees and blobs (normally I use `git cat-file -p` instead, like I did in this
`gitdatamodel` document. You can see this comic for a "visual" example of how
I've approached discussing trees and blobs in the past with `git cat-file -p`
https://wizardzines.com/comics/explore-a-commit/).
> Both seem useful to me, though as the former has fewer moving pieces
> might be better for the model this document describes? I dunno.
next prev parent reply other threads:[~2025-11-05 16:27 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
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 [this message]
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=7217ae44-5ad5-468c-b76b-c485247fb2f4@app.fastmail.com \
--to=julia@jvns$(echo .)ca \
--cc=ben.knoble@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=gitgitgadget@gmail$(echo .)com \
--cc=gitster@pobox$(echo .)com \
--cc=kristofferhaugsbakk@fastmail$(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