On Mon, 8 Aug 2016 09:00:06 -0700 (PDT) Sharan Basappa <sharan.basa...@gmail.com> wrote:
[...] > > The contents of file "-NOTES" is in > > .git/objects/02/15040f90f133f999bac86eede7565c6d09b93d. In this > > case, that object is in one of the "pack" files. git-cat-file has > > to read through the indexes of the pack files to find that. > > > > The critical ideas are that files are stored by their *contents* > > not their *names*. Any particular blob of content has an eternally > > unique name (its hash), which will be the same in any repository > > containing a blob with the same bytes. "tree" objects are used to > > catalog the names of files and their contents. [...] > To clarify, > > 100644 blob 0215040f90f133f999bac86eede7565c6d09b93d -NOTES > > Instead of storing reference to actual file, Git stores reference to > the content rather (in the form of checksum > 0215040f90f133f999bac86eede7565c6d09b93d)? > Is -NOTES a reference stored by Git. I am thinking where does Git get > the file name if it does not store it in someplace originally? Well, there are exactly three types of objects in Git repos: blobs, trees and commits. Files are stored as blobs. Blobs have no "file names" attached to them; in fact, they keep no associated metadata at all. Since humans routinely manipulate data kept in files using hierarchical files systems, Git mirrors this approach by using tree objects. A tree object serves the same purpose a directory does on a file system: it maps human-defined names of the files to their contents. So a tree object contains a set of entries -- each representing a single file or a subdirectory. Each entry has three "fields" a (simplified) file mode, the hash value of the entry's contents (its address, that is) and the human-friendly name -- taken from the source filesystem. Subdirectory entries refer to other tree objects and file entries refer to blobs. Each commit object refers to exactly one tree object representing the root of the project. Conceptually, a commit is created by starting from the project's root directory and going all the way down -- into subdirectories, considering all the tracked files on each level and creating appropriate tree and blob entries for everything found. Of course, the real implementation is much more complex to perform with the utmost speed possible. I think you should read the famous (and old) "Git from the bottom up" document [1]. It takes an unusual approach at explaining Git by actually dealing with its data model -- rather than commands to manipulate the repository. 1. https://jwiegley.github.io/git-from-the-bottom-up/ -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
