public inbox for git@vger.kernel.org 
 help / color / mirror / Atom feed
From: Ben Knoble <ben.knoble@gmail•com>
To: Julia Evans <julia@jvns•ca>
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, 5 Nov 2025 22:07:57 -0500	[thread overview]
Message-ID: <875BAB6E-724A-4AB3-85D7-8750667949E5@gmail.com> (raw)
In-Reply-To: <7217ae44-5ad5-468c-b76b-c485247fb2f4@app.fastmail.com>


> Le 5 nov. 2025 à 11:27, Julia Evans <julia@jvns•ca> a écrit :
> 
> 
> 
> 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/).

Fair enough. Here’s a post I “stole” ;) the shapes from, for posterity:

https://github.blog/open-source/git/commits-are-snapshots-not-diffs 

My larger point was: since these are the diagrams I’m imagining we want to convey to a reader, perhaps ID can be omitted for brevity? IOW, the relationship between objects is the thing to highlight.

OTOH, when exploring the data, especially at the plumbing level it seems we have to do the “pointer-chasing” ourselves (see cat-file).

So idk. 

  reply	other threads:[~2025-11-06  3:08 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
2025-11-06  3:07                             ` Ben Knoble [this message]
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=875BAB6E-724A-4AB3-85D7-8750667949E5@gmail.com \
    --to=ben.knoble@gmail$(echo .)com \
    --cc=git@vger$(echo .)kernel.org \
    --cc=gitgitgadget@gmail$(echo .)com \
    --cc=gitster@pobox$(echo .)com \
    --cc=julia@jvns$(echo .)ca \
    --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