{"thread":{"id":"1564","subject":"Subject: [PATCH] Assorted changes to glossary","startedAt":"2005-08-18T01:20:08Z","lastAt":"2005-08-18T01:20:08Z","messageCount":1,"participants":["Johannes Schindelin"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"7482","messageId":"Pine.LNX.4.63.0508180319320.25908@wgmdd8.biozentrum.uni-wuerzburg.de","threadId":"1564","inReplyTo":null,"subject":"Subject: [PATCH] Assorted changes to glossary","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2005-08-18T01:20:08Z","receivedAt":"2005-08-18T01:20:08Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Based on the discussion on the git list, here are some important changes\nto the glossary. (There is no cache, but an index. Use \"object name\"\nrather than \"SHA1\". Reorder. Clarify.)\n\nSigned-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>\n---\n\n Documentation/glossary.txt |  104 ++++++++++++++++++++++++++------------------\n 1 files changed, 61 insertions(+), 43 deletions(-)\n\n8d8a819f8f1d93c460c0b76a006f1a3830fb1f06\ndiff --git a/Documentation/glossary.txt b/Documentation/glossary.txt\n--- a/Documentation/glossary.txt\n+++ b/Documentation/glossary.txt\n@@ -3,21 +3,27 @@ object::\n \tthe SHA1 of its contents. Consequently, an object can not\n \tbe changed.\n \n+object name::\n+\tThe unique identifier of an object. The hash of the object's contents\n+\tusing the Secure Hash Algorithm 1 and usually represented by the 40\n+\tcharacter hexadecimal encoding of the hash of the object (possibly\n+\tfollowed by a white space).\n+\n SHA1::\n-\tA 20-byte sequence (or 41-byte file containing the hex\n-\trepresentation and a newline). It is calculated from the\n-\tcontents of an object by the Secure Hash Algorithm 1.\n+\tSynonym for object name.\n+\n+object identifier::\n+\tSynonym for object name.\n+\n+hash::\n+\tIn git's context, synonym to object name.\n \n object database::\n \tStores a set of \"objects\", and an individial object is identified\n-\tby its SHA1 (its ref). The objects are either stored as single\n-\tfiles, or live inside of packs.\n-\n-object name::\n-\tSynonym for SHA1.\n+\tby its object name. The object usually live in $GIT_DIR/objects/.\n \n blob object::\n-\tUntyped object, i.e. the contents of a file.\n+\tUntyped object, e.g. the contents of a file.\n \n tree object::\n \tAn object containing a list of blob and/or tree objects.\n@@ -29,42 +35,43 @@ tree::\n \tdependent blob and tree objects (i.e. a stored representation\n \tof a working tree).\n \n-cache::\n-\tA collection of files whose contents are stored as objects.\n-\tThe cache is a stored version of your working tree. Well, can\n-\talso contain a second, and even a third version of a working\n-\ttree, which are used when merging.\n+index::\n+\tA collection of files with stat information, whose contents are\n+\tstored as objects. The cache is a stored version of your working\n+\ttree. Truth be told, it can also contain a second, and even a third\n+\tversion of a working tree, which are used when merging.\n \n-cache entry::\n+index entry::\n \tThe information regarding a particular file, stored in the index.\n-\tA cache entry can be unmerged, if a merge was started, but not\n+\tAn index entry can be unmerged, if a merge was started, but not\n \tyet finished (i.e. if the cache contains multiple versions of\n \tthat file).\n \n-index::\n-\tContains information about the cache contents, in particular\n-\ttimestamps and mode flags (\"stat information\") for the files\n-\tstored in the cache. An unmerged index is an index which contains\n-\tunmerged cache entries.\n+unmerged index:\n+\tAn index which contains unmerged index entries.\n+\n+cache::\n+\tObsolete for: index.\n \n working tree::\n-\tThe set of files and directories currently being worked on.\n-\tThink \"ls -laR\"\n+\tThe set of files and directories currently being worked on,\n+\ti.e. you can work in your working tree without using git at all.\n \n directory::\n \tThe list you get with \"ls\" :-)\n \n-checkout::\n-\tThe action of updating the working tree to a revision which was\n-\tstored in the object database.\n-\n revision::\n \tA particular state of files and directories which was stored in\n \tthe object database. It is referenced by a commit object.\n \n+checkout::\n+\tThe action of updating the working tree to a revision which was\n+\tstored in the object database.\n+\n commit::\n-\tThe action of storing the current state of the cache in the\n+\tAs a verb: The action of storing the current state of the cache in the\n \tobject database. The result is a revision.\n+\tAs a noun: Short hand for commit object.\n \n commit object::\n \tAn object which contains the information about a particular\n@@ -72,14 +79,15 @@ commit object::\n \ttree object which corresponds to the top directory of the\n \tstored revision.\n \n+parent::\n+\tA commit object contains a (possibly empty) list of the logical\n+\tpredecessor(s) in the line of development, i.e. its parents.\n+\n changeset::\n \tBitKeeper/cvsps speak for \"commit\". Since git does not store\n \tchanges, but states, it really does not make sense to use\n \tthe term \"changesets\" with git.\n \n-ent::\n-\tFavorite synonym to \"tree-ish\" by some total geeks.\n-\n clean::\n \tA working tree is clean, if it corresponds to the revision\n \treferenced by the current head.\n@@ -94,13 +102,12 @@ head::\n \n branch::\n \tA non-cyclical graph of revisions, i.e. the complete history of\n-\ta particular revision, which does not (yet) have children, which\n-\tis called the branch head. The branch heads are stored in\n-\t$GIT_DIR/refs/heads/.\n+\ta particular revision, which is called the branch head. The\n+\tbranch heads are stored in $GIT_DIR/refs/heads/.\n \n ref::\n \tA 40-byte hex representation of a SHA1 pointing to a particular\n-\tobject. These are stored in $GIT_DIR/refs/.\n+\tobject. These may be stored in $GIT_DIR/refs/.\n \n head ref::\n \tA ref pointing to a head. Often, this is abbreviated to \"head\".\n@@ -108,7 +115,10 @@ head ref::\n \n tree-ish::\n \tA ref pointing to either a commit object, a tree object, or a\n-\ttag object pointing to a commit or tree object.\n+\ttag object pointing to a tag or commit or tree object.\n+\n+ent::\n+\tFavorite synonym to \"tree-ish\" by some total geeks.\n \n tag object::\n \tAn object containing a ref pointing to another object. It can\n@@ -120,6 +130,8 @@ tag::\n \ta tag is not changed by a commit. Tags (not tag objects) are\n \tstored in $GIT_DIR/refs/tags/. A git tag has nothing to do with\n \ta Lisp tag (which is called object type in git's context).\n+\tA tag is most typically used to mark a particular point in the\n+\tcommit ancestry chain.\n \n merge::\n \tTo merge branches means to try to accumulate the changes since a\n@@ -133,9 +145,18 @@ resolve::\n \n repository::\n \tA collection of refs together with an object database containing\n-\tall objects, which are reachable from the refs. A repository can\n+\tall objects, which are reachable from the refs, possibly accompanied\n+\tby meta data from one or more porcelains. A repository can\n \tshare an object database with other repositories.\n \n+git archive::\n+\tSynonym for repository (for arch people).\n+\n+file system::\n+\tLinus Torvalds originally designed git to be a user space file\n+\tsystem, i.e. the infrastructure to hold files and directories.\n+\tThat ensured the efficiency and speed of git.\n+\n alternate object database::\n \tVia the alternates mechanism, a repository can inherit part of its\n \tobject database from another object database, which is called\n@@ -150,10 +171,6 @@ chain::\n \treference to its successor (for example, the successor of a commit\n \tcould be one of its parents).\n \n-parent::\n-\tA commit object contains a (possibly empty) list of the logical\n-\tpredecessor(s) in the line of development, i.e. its parents.\n-\n fetch::\n \tFetching a branch means to get the branch's head ref from a\n \tremote repository, to find out which objects are missing from\n@@ -176,8 +193,8 @@ pack::\n \tspace or to transmit them efficiently).\n \n pack index::\n-\tContains offsets into a pack, so the pack can be used instead of\n-\tthe unpacked objects.\n+\tThe list of identifiers, and other information, of the objects in a\n+\tpack, to assist in efficiently accessing the contents of a pack. \n \n plumbing::\n \tCute name for core git.\n@@ -196,3 +213,4 @@ SCM::\n \n dircache::\n \tYou are *waaaaay* behind.\n+\n"}]}