Documentation/glossary.txt

   1 alternate object database::
   2         Via the alternates mechanism, a repository can inherit part of its
   3         object database from another object database, which is called
   4         "alternate".
   5
   6 blob object::
   7         Untyped object, e.g. the contents of a file.
   8
   9 branch::
  10         A non-cyclical graph of revisions, i.e. the complete history of
  11         a particular revision, which is called the branch head. The
  12         branch heads are stored in `$GIT_DIR/refs/heads/`.
  13
  14 cache::
  15         Obsolete for: index.
  16
  17 chain::
  18         A list of objects, where each object in the list contains a
  19         reference to its successor (for example, the successor of a commit
  20         could be one of its parents).
  21
  22 changeset::
  23         BitKeeper/cvsps speak for "commit". Since git does not store
  24         changes, but states, it really does not make sense to use
  25         the term "changesets" with git.
  26
  27 checkout::
  28         The action of updating the working tree to a revision which was
  29         stored in the object database.
  30
  31 clean::
  32         A working tree is clean, if it corresponds to the revision
  33         referenced by the current head.  Also see "dirty".
  34
  35 commit::
  36         As a verb: The action of storing the current state of the index in the
  37         object database. The result is a revision.
  38         As a noun: Short hand for commit object.
  39
  40 commit object::
  41         An object which contains the information about a particular
  42         revision, such as parents, committer, author, date and the
  43         tree object which corresponds to the top directory of the
  44         stored revision.
  45
  46 core git::
  47         Fundamental data structures and utilities of git. Exposes only
  48         limited source code management tools.
  49
  50 DAG::
  51         Directed acyclic graph. The commit objects form a directed acyclic
  52         graph, because they have parents (directed), and the graph of commit
  53         objects is acyclic (there is no chain which begins and ends with the
  54         same object).
  55
  56 dircache::
  57         You are *waaaaay* behind.
  58
  59 dirty::
  60         A working tree is said to be dirty if it contains modifications
  61         which have not been committed to the current branch.
  62
  63 directory::
  64         The list you get with "ls" :-)
  65
  66 ent::
  67         Favorite synonym to "tree-ish" by some total geeks. See
  68         `http://en.wikipedia.org/wiki/Ent_(Middle-earth)` for an in-depth
  69         explanation.
  70
  71 fetch::
  72         Fetching a branch means to get the branch's head ref from a
  73         remote repository, to find out which objects are missing from
  74         the local object database, and to get them, too.
  75
  76 file system::
  77         Linus Torvalds originally designed git to be a user space file
  78         system, i.e. the infrastructure to hold files and directories.
  79         That ensured the efficiency and speed of git.
  80
  81 git archive::
  82         Synonym for repository (for arch people).
  83
  84 hash::
  85         In git's context, synonym to object name.
  86
  87 head::
  88         The top of a branch. It contains a ref to the corresponding
  89         commit object.
  90
  91 head ref::
  92         A ref pointing to a head. Often, this is abbreviated to "head".
  93         Head refs are stored in `$GIT_DIR/refs/heads/`.
  94
  95 index::
  96         A collection of files with stat information, whose contents are
  97         stored as objects. The index is a stored version of your working
  98         tree. Truth be told, it can also contain a second, and even a third
  99         version of a working tree, which are used when merging.
 100
 101 index entry::
 102         The information regarding a particular file, stored in the index.
 103         An index entry can be unmerged, if a merge was started, but not
 104         yet finished (i.e. if the index contains multiple versions of
 105         that file).
 106
 107 master::
 108         The default branch. Whenever you create a git repository, a branch
 109         named "master" is created, and becomes the active branch. In most
 110         cases, this contains the local development.
 111
 112
 113 merge::
 114         To merge branches means to try to accumulate the changes since a
 115         common ancestor and apply them to the first branch. An automatic
 116         merge uses heuristics to accomplish that. Evidently, an automatic
 117         merge can fail.
 118
 119 object::
 120         The unit of storage in git. It is uniquely identified by
 121         the SHA1 of its contents. Consequently, an object can not
 122         be changed.
 123
 124 object database::
 125         Stores a set of "objects", and an individual object is identified
 126         by its object name. The objects usually live in `$GIT_DIR/objects/`.
 127
 128 object identifier::
 129         Synonym for object name.
 130
 131 object name::
 132         The unique identifier of an object. The hash of the object's contents
 133         using the Secure Hash Algorithm 1 and usually represented by the 40
 134         character hexadecimal encoding of the hash of the object (possibly
 135         followed by a white space).
 136
 137 object type:
 138         One of the identifiers "commit","tree","tag" and "blob" describing
 139         the type of an object.
 140
 141 octopus::
 142         To merge more than two branches. Also denotes an intelligent
 143         predator.
 144
 145 origin::
 146         The default upstream branch. Most projects have one upstream
 147         project which they track, and by default 'origin' is used for
 148         that purpose.  New updates from upstream will be fetched into
 149         this branch; you should never commit to it yourself.
 150
 151 pack::
 152         A set of objects which have been compressed into one file (to save
 153         space or to transmit them efficiently).
 154
 155 pack index::
 156         The list of identifiers, and other information, of the objects in a
 157         pack, to assist in efficiently accessing the contents of a pack.
 158
 159 parent::
 160         A commit object contains a (possibly empty) list of the logical
 161         predecessor(s) in the line of development, i.e. its parents.
 162
 163 plumbing::
 164         Cute name for core git.
 165
 166 porcelain::
 167         Cute name for programs and program suites depending on core git,
 168         presenting a high level access to core git. Porcelains expose
 169         more of a SCM interface than the plumbing.
 170
 171 pull::
 172         Pulling a branch means to fetch it and merge it.
 173
 174 push::
 175         Pushing a branch means to get the branch's head ref from a remote
 176         repository, find out if it is an ancestor to the branch's local
 177         head ref is a direct, and in that case, putting all objects, which
 178         are reachable from the local head ref, and which are missing from
 179         the remote repository, into the remote object database, and updating
 180         the remote head ref. If the remote head is not an ancestor to the
 181         local head, the push fails.
 182
 183 reachable::
 184         An object is reachable from a ref/commit/tree/tag, if there is a
 185         chain leading from the latter to the former.
 186
 187 rebase::
 188         To clean a branch by starting from the head of the main line of
 189         development ("master"), and reapply the (possibly cherry-picked)
 190         changes from that branch.
 191
 192 ref::
 193         A 40-byte hex representation of a SHA1 pointing to a particular
 194         object. These may be stored in `$GIT_DIR/refs/`.
 195
 196 repository::
 197         A collection of refs together with an object database containing
 198         all objects, which are reachable from the refs, possibly accompanied
 199         by meta data from one or more porcelains. A repository can
 200         share an object database with other repositories.
 201
 202 resolve::
 203         The action of fixing up manually what a failed automatic merge
 204         left behind.
 205
 206 revision::
 207         A particular state of files and directories which was stored in
 208         the object database. It is referenced by a commit object.
 209
 210 rewind::
 211         To throw away part of the development, i.e. to assign the head to
 212         an earlier revision.
 213
 214 SCM::
 215         Source code management (tool).
 216
 217 SHA1::
 218         Synonym for object name.
 219
 220 tree object::
 221         An object containing a list of file names and modes along with refs
 222         to the associated blob and/or tree objects. A tree is equivalent
 223         to a directory.
 224
 225 tree::
 226         Either a working tree, or a tree object together with the
 227         dependent blob and tree objects (i.e. a stored representation
 228         of a working tree).
 229
 230 tree-ish::
 231         A ref pointing to either a commit object, a tree object, or a
 232         tag object pointing to a tag or commit or tree object.
 233
 234 tag object::
 235         An object containing a ref pointing to another object, which can
 236         contain a message just like a commit object. It can also
 237         contain a (PGP) signature, in which case it is called a "signed
 238         tag object".
 239
 240 tag::
 241         A ref pointing to a tag or commit object. In contrast to a head,
 242         a tag is not changed by a commit. Tags (not tag objects) are
 243         stored in `$GIT_DIR/refs/tags/`. A git tag has nothing to do with
 244         a Lisp tag (which is called object type in git's context).
 245         A tag is most typically used to mark a particular point in the
 246         commit ancestry chain.
 247
 248 unmerged index:
 249         An index which contains unmerged index entries.
 250
 251 working tree::
 252         The set of files and directories currently being worked on,
 253         i.e. you can work in your working tree without using git at all.
 254