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