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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Emily Shaffer <emilyshaffer@xxxxxxxxxx> 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.

> +
> +- 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.





[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux