Re: [Git Developer Blog] [PATCH] post: a tour of git's object types

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 21, 2019, 04:34 UTC
Message-ID: <xmqqk18ylns5.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <20191019002045.148579-1-emilyshaffer@google.com>

Emily Shaffer <emilyshaffer@google.com> writes:

> +Under the covers, Git is mostly a directed graph of objects. Those objects come
> +in four flavors; from root to leaf (generally), those flavors are:

Is "acyclic" worth mentioning, I wonder.

Show 13 quoted lines

> +
> +- Tag
> +- Commit
> +- Tree
> +- Blob
> +
> +We'll take a closer look in the opposite order, though.
> +
> +# Blob
> +
> +Surprise! It's a file. Well, kind of - it can also be a symlink to a file - but
> +this is the most atomic type of object. We'll explore these a little more later,
> +but really, it's just a file.

It may be easier to understand if we said it is "just a stream of bytes". And of course the simplest applciation of a stream of bytes is to store contents of a file, but it also can be used to store the value of a symbolic file, and also can be used to store the notes.

So, really, it's just a stream of bytes.

> +A tree references zero or more trees or blobs. Said another way, a tree holds
> +one or more trees or files.

That captures only half of a tree. It is a mapping from names to objects. Of course, being a mapping, it references other objects (by the way, do not limit the contents to "trees or blobs") on the value side of the mapping.

    A tree gives names to objects within its scope.  It maps names
    to objects, typically a blob or a tree.  Thus, it can be used
    (and it indeed is used) to represent a directory full of files
    by storing mapping from filenames to blob objects that store
    their contents.  A subdirectory can be represented by having a
    mapping from its name to the tree object that represents the
    contents of the subdirectory.

> This sounds familiar - basically, a tree is a
> +directory. (Okay, or a symlink to a directory.) It points to more trees

No, I do not think it is a symlink to a directory. What makes you think so?

I'd stop here for now. I am certain that I haven't read enough to say things either negative or positive about the "naming is hard, naming used in the canonical documentation of Git is unnecessary hard to read and we propose a better wording" premise given by the introduction, so I won't comment on it yet.

Thanks.