Re: [PATCH v7] doc: add an explanation of Git's data model
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Nov 12, 2025, 20:26 UTC
- 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:
Show 23 quoted lines
> +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.