GIT Glossary ============ Aug 2005 [[ref_SCM]]SCM:: Source code management (tool). [[ref_SHA1]]SHA1:: A 20-byte sequence (or 41-byte file containing the hex representation and a newline). It is calculated from the contents of an <> by the Secure Hash Algorithm 1. [[ref_alternate_object_database]]alternate object database:: Via the alternates mechanism, a <> can inherit part of its <> from another <>, which is called "alternate". [[ref_blob_object]]blob object:: Untyped <>, i.e. the contents of a file. [[ref_branch]]branch:: A non-cyclical graph of revisions, i.e. the complete history of a particular <>, which does not (yet) have children, which is called the <> <>. The <> heads are stored in $GIT_DIR/refs/heads/. [[ref_cache]]cache:: A collection of files whose contents are stored as objects. The <> is a stored version of your <>. Well, can also contain a second, and even a third version of a working <>, which are used when merging. [[ref_cache_entry]]cache entry:: The information regarding a particular file, stored in the <>. A <> can be unmerged, if a <> was started, but not yet finished (i.e. if the <> contains multiple versions of that file). [[ref_chain]]chain:: A list of objects, where each <> in the list contains a reference to its successor (for example, the successor of a <> could be one of its parents). [[ref_changeset]]changeset:: BitKeeper/cvsps speak for "<>". Since git does not store changes, but states, it really does not make sense to use the term "changesets" with git. [[ref_checkout]]checkout:: The action of updating the <> to a <> which was stored in the <>. [[ref_clean]]clean:: A <> is <>, if it corresponds to the <> referenced by the current <>. [[ref_commit]]commit:: The action of storing the current state of the <> in the <>. The result is a <>. [[ref_commit_object]]commit object:: An <> which contains the information about a particular <>, such as parents, committer, author, date and the <> which corresponds to the top <> of the stored <>. [[ref_dircache]]dircache:: You are *waaaaay* behind. [[ref_directory]]directory:: The list you get with "ls" :-) [[ref_dirty]]dirty:: A <> is said to be <> if it contains modifications which have not been committed to the current <>. [[ref_ent]]ent:: Favorite synonym to "<>" by some total geeks. [[ref_fetch]]fetch:: Fetching a <> means to get the <>'s <> from a remote <>, to find out which objects are missing from the local <>, and to get them, too. [[ref_head]]head:: The top of a <>. It contains a <> to the corresponding <>. [[ref_head_ref]]head ref:: A <> pointing to a <>. Often, this is abbreviated to "<>". Head refs are stored in $GIT_DIR/refs/heads/. [[ref_index]]index:: Contains information about the <> contents, in particular timestamps and mode flags ("stat information") for the files stored in the <>. An unmerged <> is an <> which contains unmerged <> entries. [[ref_merge]]merge:: To <> branches means to try to accumulate the changes since a common ancestor and apply them to the first <>. An automatic <> uses heuristics to accomplish that. Evidently, an automatic <> can fail. [[ref_object]]object:: The unit of storage in GIT. It is uniquely identified by the <> of its contents. Consequently, an <> can not be changed. [[ref_object_database]]object database:: Stores a set of "objects", and an individial <> is identified by its <> (its <>). The objects are either stored as single files, or live inside of packs. [[ref_object_name]]object name:: Synonym for <>. [[ref_pack]]pack:: A set of objects which have been compressed into one file (to save space or to transmit them efficiently). [[ref_pack_index]]pack index:: Contains offsets into a <>, so the <> can be used instead of the unpacked objects. [[ref_parent]]parent:: A <> contains a (possibly empty) list of the logical predecessor(s) in the line of development, i.e. its parents. [[ref_plumbing]]plumbing:: Cute name for core git. [[ref_porcelain]]porcelain:: Cute name for programs and program suites depending on core git, presenting a high level access to core git. Porcelains expose more of a <> interface than the <>. [[ref_pull]]pull:: Pulling a <> means to <> it and <> it. [[ref_push]]push:: Pushing a <> means to get the <>'s <> from a remote <>, find out if it is an ancestor to the <>'s local <> is a direct, and in that case, putting all objects, which are <> from the local <>, and which are missing from the remote <>, into the remote <>, and updating the remote <>. If the remote <> is not an ancestor to the local <>, the <> fails. [[ref_reachable]]reachable:: An <> is <> from a <>/<>/<>/<>, if there is a <> leading from the latter to the former. [[ref_ref]]ref:: A 40-byte hex representation of a <> pointing to a particular <>. These are stored in $GIT_DIR/refs/. [[ref_repository]]repository:: A collection of refs together with an <> containing all objects, which are <> from the refs. A <> can share an <> with other repositories. [[ref_resolve]]resolve:: The action of fixing up manually what a failed automatic <> left behind. [[ref_revision]]revision:: A particular state of files and directories which was stored in the <>. It is referenced by a <>. [[ref_tag]]tag:: A <> pointing to a <> or <>. In contrast to a <>, a <> is not changed by a <>. Tags (not <> objects) are stored in $GIT_DIR/refs/tags/. A git <> has nothing to do with a Lisp <> (which is called <> type in git's context). [[ref_tag_object]]tag object:: An <> containing a <> pointing to another <>. It can contain a (PGP) signature, in which case it is called "signed <>". [[ref_tree]]tree:: Either a <>, or a <> together with the dependent blob and <> objects (i.e. a stored representation of a <>). [[ref_tree_object]]tree object:: An <> containing a list of blob and/or <> objects. (A <> usually corresponds to a <> without subdirectories). [[ref_tree-ish]]tree-ish:: A <> pointing to either a <>, a <>, or a <> pointing to a <> or <>. [[ref_working_tree]]working tree:: The set of files and directories currently being worked on. Think "ls -laR"