From: Junio C Hamano <gitster@pobox.com>
Date: Wed, 12 Nov 2025 20:26:26 GMT
Subject: Re: [PATCH v7] doc: add an explanation of Git's data model
Message-ID: <xmqqy0obov4d.fsf@gitster.g>
In-Reply-To: <pull.1981.v7.git.1762977200244.gitgitgadget@gmail.com>

"Julia Evans via GitGitGadget" <gitgitgadget@gmail.com> writes:

> +2. The *file type*, which must be one of these five types:
> +  - *regular file*
> +  - *executable file*
> +  - *symbolic link*
> +  - *directory*
> +  - *gitlink* (for use with submodules)
> +3. The <<object-id,*object ID*>> with the contents of the file, directory,
> +   or gitlink.
> ++
> +For example, this is how a tree containing one directory (`src`) and one file
> +(`README.md`) is stored:
> ++
> +----
> +100644 blob 8728a858d9d21a8c78488c8b4e70e531b659141f README.md
> +040000 tree 89b1d2e0495f66d6929f4ff76ff1bb07fc41947d src
> +----
> +
> +NOTE: In the output above, Git displays the file type of each tree entry
> +using a format that's loosely modelled on Unix file modes (`100644` is
> +"regular file", `100755` is "executable file", `120000` is "symbolic
> +link", `040000` is "directory", and `160000` is "gitlink"). It also
> +displays the object's type: `blob` for files and symlinks, `tree` for
> +directories, and `commit` for gitlinks.

As a description of the data model, moving the exact bit assignment
to a side note like the above hunk (relative to the previous
iteration) does make the body text less cluttered, which I think is
a welcome change.