Documentation/glossary.txt

   1 object::
   2         The unit of storage in GIT. It is uniquely identified by
   3         the SHA1 of its contents. Consequently, an object can not
   4         be changed.
   5
   6 SHA1::
   7         A 20-byte sequence (or 41-byte file containing the hex
   8         representation and a newline). It is calculated from the
   9         contents of an object by the Secure Hash Algorithm 1.
  10
  11 object database::
  12         Stores a set of "objects", and an individial object is identified
  13         by its SHA1 (its ref). The objects are either stored as single
  14         files, or live inside of packs.
  15
  16 object name::
  17         Synonym for SHA1.
  18
  19 blob object::
  20         Untyped object, i.e. the contents of a file.
  21
  22 tree object::
  23         An object containing a list of blob and/or tree objects.
  24         (A tree usually corresponds to a directory without
  25         subdirectories).
  26
  27 tree::
  28         Either a working tree, or a tree object together with the
  29         dependent blob and tree objects (i.e. a stored representation
  30         of a working tree).
  31
  32 cache::
  33         A collection of files whose contents are stored as objects.
  34         The cache is a stored version of your working tree. Well, can
  35         also contain a second, and even a third version of a working
  36         tree, which are used when merging.
  37
  38 cache entry::
  39         The information regarding a particular file, stored in the index.
  40         A cache entry can be unmerged, if a merge was started, but not
  41         yet finished (i.e. if the cache contains multiple versions of
  42         that file).
  43
  44 index::
  45         Contains information about the cache contents, in particular
  46         timestamps and mode flags ("stat information") for the files
  47         stored in the cache. An unmerged index is an index which contains
  48         unmerged cache entries.
  49
  50 working tree::
  51         The set of files and directories currently being worked on.
  52         Think "ls -laR"
  53
  54 directory::
  55         The list you get with "ls" :-)
  56
  57 checkout::
  58         The action of updating the working tree to a revision which was
  59         stored in the object database.
  60
  61 revision::
  62         A particular state of files and directories which was stored in
  63         the object database. It is referenced by a commit object.
  64
  65 commit::
  66         The action of storing the current state of the cache in the
  67         object database. The result is a revision.
  68
  69 commit object::
  70         An object which contains the information about a particular
  71         revision, such as parents, committer, author, date and the
  72         tree object which corresponds to the top directory of the
  73         stored revision.
  74
  75 changeset::
  76         BitKeeper/cvsps speak for "commit". Since git does not store
  77         changes, but states, it really does not make sense to use
  78         the term "changesets" with git.
  79
  80 ent::
  81         Favorite synonym to "tree-ish" by some total geeks.
  82
  83 clean::
  84         A working tree is clean, if it corresponds to the revision
  85         referenced by the current head.
  86
  87 dirty::
  88         A working tree is said to be dirty if it contains modifications
  89         which have not been committed to the current branch.
  90
  91 head::
  92         The top of a branch. It contains a ref to the corresponding
  93         commit object.
  94
  95 branch::
  96         A non-cyclical graph of revisions, i.e. the complete history of
  97         a particular revision, which does not (yet) have children, which
  98         is called the branch head. The branch heads are stored in
  99         $GIT_DIR/refs/heads/.
 100
 101 ref::
 102         A 40-byte hex representation of a SHA1 pointing to a particular
 103         object. These are stored in $GIT_DIR/refs/.
 104
 105 head ref::
 106         A ref pointing to a head. Often, this is abbreviated to "head".
 107         Head refs are stored in $GIT_DIR/refs/heads/.
 108
 109 tree-ish::
 110         A ref pointing to either a commit object, a tree object, or a
 111         tag object pointing to a commit or tree object.
 112
 113 tag object::
 114         An object containing a ref pointing to another object. It can
 115         contain a (PGP) signature, in which case it is called "signed
 116         tag object".
 117
 118 tag::
 119         A ref pointing to a tag or commit object. In contrast to a head,
 120         a tag is not changed by a commit. Tags (not tag objects) are
 121         stored in $GIT_DIR/refs/tags/. A git tag has nothing to do with
 122         a Lisp tag (which is called object type in git's context).
 123
 124 merge::
 125         To merge branches means to try to accumulate the changes since a
 126         common ancestor and apply them to the first branch. An automatic
 127         merge uses heuristics to accomplish that. Evidently, an automatic
 128         merge can fail.
 129
 130 resolve::
 131         The action of fixing up manually what a failed automatic merge
 132         left behind.
 133
 134 repository::
 135         A collection of refs together with an object database containing
 136         all objects, which are reachable from the refs. A repository can
 137         share an object database with other repositories.
 138
 139 alternate object database::
 140         Via the alternates mechanism, a repository can inherit part of its
 141         object database from another object database, which is called
 142         "alternate".
 143
 144 reachable::
 145         An object is reachable from a ref/commit/tree/tag, if there is a
 146         chain leading from the latter to the former.
 147
 148 chain::
 149         A list of objects, where each object in the list contains a
 150         reference to its successor (for example, the successor of a commit
 151         could be one of its parents).
 152
 153 parent::
 154         A commit object contains a (possibly empty) list of the logical
 155         predecessor(s) in the line of development, i.e. its parents.
 156
 157 fetch::
 158         Fetching a branch means to get the branch's head ref from a
 159         remote repository, to find out which objects are missing from
 160         the local object database, and to get them, too.
 161
 162 pull::
 163         Pulling a branch means to fetch it and merge it.
 164
 165 push::
 166         Pushing a branch means to get the branch's head ref from a remote
 167         repository, find out if it is an ancestor to the branch's local
 168         head ref is a direct, and in that case, putting all objects, which
 169         are reachable from the local head ref, and which are missing from
 170         the remote repository, into the remote object database, and updating
 171         the remote head ref. If the remote head is not an ancestor to the
 172         local head, the push fails.
 173
 174 pack::
 175         A set of objects which have been compressed into one file (to save
 176         space or to transmit them efficiently).
 177
 178 pack index::
 179         Contains offsets into a pack, so the pack can be used instead of
 180         the unpacked objects.
 181
 182 plumbing::
 183         Cute name for core git.
 184
 185 porcelain::
 186         Cute name for programs and program suites depending on core git,
 187         presenting a high level access to core git. Porcelains expose
 188         more of a SCM interface than the plumbing.
 189
 190 object type:
 191         One of the identifiers "commit","tree","tag" and "blob" describing
 192         the type of an object.
 193
 194 SCM::
 195         Source code management (tool).
 196
 197 dircache::
 198         You are *waaaaay* behind.