object::
- The unit of storage in GIT. It is uniquely identified by
+ The unit of storage in git. It is uniquely identified by
the SHA1 of its contents. Consequently, an object can not
be changed.
object database::
Stores a set of "objects", and an individial object is identified
- by its object name. The object usually live in $GIT_DIR/objects/.
+ by its object name. The objects usually live in `$GIT_DIR/objects/`.
blob object::
Untyped object, e.g. the contents of a file.
tree object::
An object containing a list of file names and modes along with refs
- to the associated blob and/or tree objects. A tree object is
- equivalent to a directory.
+ to the associated blob and/or tree objects. A tree is equivalent
+ to a directory.
tree::
Either a working tree, or a tree object together with the
dependent blob and tree objects (i.e. a stored representation
of a working tree).
+DAG::
+ Directed acyclic graph. The commit objects form a directed acyclic
+ graph, because they have parents (directed), and the graph of commit
+ objects is acyclic (there is no chain which begins and ends with the
+ same object).
+
index::
A collection of files with stat information, whose contents are
- stored as objects. The cache is a stored version of your working
+ stored as objects. The index is a stored version of your working
tree. Truth be told, it can also contain a second, and even a third
version of a working tree, which are used when merging.
index entry::
The information regarding a particular file, stored in the index.
An index entry can be unmerged, if a merge was started, but not
- yet finished (i.e. if the cache contains multiple versions of
+ yet finished (i.e. if the index contains multiple versions of
that file).
unmerged index:
stored in the object database.
commit::
- As a verb: The action of storing the current state of the cache in the
+ As a verb: The action of storing the current state of the index in the
object database. The result is a revision.
As a noun: Short hand for commit object.
branch::
A non-cyclical graph of revisions, i.e. the complete history of
a particular revision, which is called the branch head. The
- branch heads are stored in $GIT_DIR/refs/heads/.
+ branch heads are stored in `$GIT_DIR/refs/heads/`.
ref::
A 40-byte hex representation of a SHA1 pointing to a particular
- object. These may be stored in $GIT_DIR/refs/.
+ object. These may be stored in `$GIT_DIR/refs/`.
head ref::
A ref pointing to a head. Often, this is abbreviated to "head".
- Head refs are stored in $GIT_DIR/refs/heads/.
+ Head refs are stored in `$GIT_DIR/refs/heads/`.
tree-ish::
A ref pointing to either a commit object, a tree object, or a
ent::
Favorite synonym to "tree-ish" by some total geeks. See
- http://en.wikipedia.org/wiki/Ent_(Middle-earth) for an in-depth
+ `http://en.wikipedia.org/wiki/Ent_(Middle-earth)` for an in-depth
explanation.
tag object::
tag::
A ref pointing to a tag or commit object. In contrast to a head,
a tag is not changed by a commit. Tags (not tag objects) are
- stored in $GIT_DIR/refs/tags/. A git tag has nothing to do with
+ stored in `$GIT_DIR/refs/tags/`. A git tag has nothing to do with
a Lisp tag (which is called object type in git's context).
A tag is most typically used to mark a particular point in the
commit ancestry chain.
merge uses heuristics to accomplish that. Evidently, an automatic
merge can fail.
+octopus::
+ To merge more than two branches. Also denotes an intelligent
+ predator.
+
resolve::
The action of fixing up manually what a failed automatic merge
left behind.