<p>"git-ls-files --unmerged" and "git-ls-files --stage" can be used to examine\r
detailed information on unmerged paths.</p>\r
<p>For an unmerged path, instead of recording a single mode/SHA1 pair,\r
-the dircache records up to three such pairs; one from tree O in stage\r
+the index records up to three such pairs; one from tree O in stage\r
1, A in stage 2, and B in stage 3. This information can be used by\r
the user (or the porcelain) to see what should eventually be recorded at the\r
path. (see git-read-tree for more information on state)</p>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 08-May-2007 00:32:26 UTC\r
+Last updated 27-May-2007 04:28:37 UTC\r
</div>\r
</div>\r
</body>\r
detailed information on unmerged paths.
For an unmerged path, instead of recording a single mode/SHA1 pair,
-the dircache records up to three such pairs; one from tree O in stage
+the index records up to three such pairs; one from tree O in stage
1, A in stage 2, and B in stage 3. This information can be used by
the user (or the porcelain) to see what should eventually be recorded at the
path. (see git-read-tree for more information on state)
A bare repository is normally an appropriately\r
named <a href="#def_directory">directory</a> with a <tt>.git</tt> suffix that does not\r
have a locally checked-out copy of any of the files under\r
- <a href="#def_revision">revision</a> control. That is, all of the <tt>git</tt>\r
+ revision control. That is, all of the <tt>git</tt>\r
administrative and control files that would normally be present in the\r
hidden <tt>.git</tt> sub-directory are directly present in the\r
<tt>repository.git</tt> directory instead,\r
<p>\r
A list of objects, where each <a href="#def_object">object</a> in the list contains\r
a reference to its successor (for example, the successor of a\r
- <a href="#def_commit">commit</a> could be one of its parents).\r
+ <a href="#def_commit">commit</a> could be one of its <a href="#def_parent">parents</a>).\r
</p>\r
</dd>\r
<dt>\r
<dd>\r
<p>\r
An <a href="#def_object">object</a> which contains the information about a\r
- particular <a href="#def_revision">revision</a>, such as parents, committer,\r
+ particular <a href="#def_revision">revision</a>, such as <a href="#def_parent">parents</a>, committer,\r
author, date and the <a href="#def_tree_object">tree object</a> which corresponds\r
to the top <a href="#def_directory">directory</a> of the stored\r
- <a href="#def_revision">revision</a>.\r
+ revision.\r
</p>\r
</dd>\r
<dt>\r
<dd>\r
<p>\r
Normally the <a href="#def_HEAD">HEAD</a> stores the name of a\r
- <a href="#def_branch">branch</a>. However, git also allows you to check\r
- out an arbitrary commit that isn't necessarily the tip of any\r
+ <a href="#def_branch">branch</a>. However, git also allows you to <a href="#def_checkout">check out</a>\r
+ an arbitrary <a href="#def_commit">commit</a> that isn't necessarily the tip of any\r
particular branch. In this case HEAD is said to be "detached".\r
</p>\r
</dd>\r
</dt>\r
<dd>\r
<p>\r
- You are <strong>waaaaay</strong> behind.\r
+ You are <strong>waaaaay</strong> behind. See <a href="#def_index">index</a>.\r
</p>\r
</dd>\r
<dt>\r
<dd>\r
<p>\r
A <a href="#def_working_tree">working tree</a> is said to be "dirty" if\r
- it contains modifications which have not been committed to the current\r
+ it contains modifications which have not been <a href="#def_commit">committed</a> to the current\r
<a href="#def_branch">branch</a>.\r
</p>\r
</dd>\r
</p>\r
</dd>\r
<dt>\r
+<a id="def_evil_merge"></a>evil merge\r
+</dt>\r
+<dd>\r
+<p>\r
+ An evil merge is a <a href="#def_merge">merge</a> that introduces changes that\r
+ do not appear in any <a href="#def_parent">parent</a>.\r
+</p>\r
+</dd>\r
+<dt>\r
<a id="def_fast_forward"></a>fast forward\r
</dt>\r
<dd>\r
<p>\r
Grafts enables two otherwise different lines of development to be joined\r
together by recording fake ancestry information for commits. This way\r
- you can make git pretend the set of
parents a <a href="#def_commit">commit</a> has
\r+ you can make git pretend the set of
<a href="#def_parent">parents</a> a <a href="#def_commit">commit</a> has
\r is different from what was recorded when the commit was\r
created. Configured via the <tt>.git/info/grafts</tt> file.\r
</p>\r
</dt>\r
<dd>\r
<p>\r
- A
named reference to the <a href="#def_commit">commit</a> at the tip of a
\r+ A
<a href="#def_ref">named reference</a> to the <a href="#def_commit">commit</a> at the tip of a
\r <a href="#def_branch">branch</a>. Heads are stored in\r
<tt>$GIT_DIR/refs/heads/</tt>, except when using packed refs. (See\r
<a href="git-pack-refs.html">git-pack-refs(1)</a>.)\r
</dt>\r
<dd>\r
<p>\r
- The current
branch. In more detail: Your <a href="#def_working_tree">working tree</a> is normally derived from the state of the tree
\r+ The current
<a href="#def_branch">branch</a>. In more detail: Your <a href="#def_working_tree">working tree</a> is normally derived from the state of the tree
\r referred to by HEAD. HEAD is a reference to one of the\r
<a href="#def_head">heads</a> in your repository, except when using a\r
<a href="#def_detached_HEAD">detached HEAD</a>, in which case it may\r
checking. Typically, the hooks allow for a command to be pre-verified\r
and potentially aborted, and allow for a post-notification after the\r
operation is done. The hook scripts are found in the\r
- <tt>$GIT_DIR/hooks/</tt> <a href="#def_directory">directory</a>, and are enabled by simply\r
+ <tt>$GIT_DIR/hooks/</tt> directory, and are enabled by simply\r
making them executable.\r
</p>\r
</dd>\r
<dd>\r
<p>\r
A collection of files with stat information, whose contents are stored\r
- as objects. The index is a stored version of your working\r
- <a href="#def_tree">tree</a>. Truth be told, it can also contain a second, and even\r
- a third version of a <a href="#def_working_tree">working tree</a>, which are used\r
- when merging.\r
+ as objects. The index is a stored version of your\r
+ <a href="#def_working_tree">working tree</a>. Truth be told, it can also contain a second, and even\r
+ a third version of a working tree, which are used\r
+ when <a href="#def_merge">merging</a>.\r
</p>\r
</dd>\r
<dt>\r
</dt>\r
<dd>\r
<p>\r
- To <a href="#def_merge">merge</a> more than two branches. Also denotes an\r
+ To <a href="#def_merge">merge</a> more than two <a href="#def_branch">branches</a>. Also denotes an\r
intelligent predator.\r
</p>\r
</dd>\r
The default upstream <a href="#def_repository">repository</a>. Most projects have\r
at least one upstream project which they track. By default\r
<em>origin</em> is used for that purpose. New upstream updates\r
- will be fetched into remote tracking branches named\r
+ will be fetched into remote <a href="#def_tracking_branch">tracking branches</a> named\r
origin/name-of-upstream-branch, which you can see using\r
- "git <a href="#def_branch">branch</a> -r".\r
+ "<tt>git branch -r</tt>".\r
</p>\r
</dd>\r
<dt>\r
</dt>\r
<dd>\r
<p>\r
- A
<a href="#def_refspec">refspec</a> is used by <a href="#def_fetch">fetch</a> and
\r+ A
"refspec" is used by <a href="#def_fetch">fetch</a> and
\r <a href="#def_push">push</a> to describe the mapping between remote\r
<a href="#def_ref">ref</a> and local ref. They are combined with a colon in\r
the format <src>:<dst>, preceded by an optional plus sign, +.\r
</dt>\r
<dd>\r
<p>\r
- A collection of refs together with an\r
+ A collection of <a href="#def_ref">refs</a> together with an\r
<a href="#def_object_database">object database</a> containing all objects\r
which are <a href="#def_reachable">reachable</a> from the refs, possibly\r
- accompanied by meta data from one or more porcelains. A\r
- repository can share an object database with other repositories.\r
+ accompanied by meta data from one or more <a href="#def_porcelain">porcelains</a>. A\r
+ repository can share an object database with other repositories\r
+ via <a href="#def_alternate_object_database">alternates mechanism</a>.\r
</p>\r
</dd>\r
<dt>\r
</dt>\r
<dd>\r
<p>\r
- A shallow repository has an incomplete\r
- history some of whose commits have parents cauterized away (in other\r
+ A shallow <a href="#def_repository">repository</a> has an incomplete\r
+ history some of whose <a href="#def_commit">commits</a> have <a href="#def_parent">parents</a> cauterized away (in other\r
words, git is told to pretend that these commits do not have the\r
parents, even though they are recorded in the <a href="#def_commit_object">commit object</a>). This is sometimes useful when you are interested only in the\r
recent history of a project even though the real history recorded in the\r
</dt>\r
<dd>\r
<p>\r
- A <a href="#def_ref">ref</a> pointing to a tag or\r
+ A <a href="#def_ref">ref</a> pointing to a <a href="#def_tag_object">tag</a> or\r
<a href="#def_commit_object">commit object</a>. In contrast to a <a href="#def_head">head</a>,\r
a tag is not changed by a <a href="#def_commit">commit</a>. Tags (not\r
<a href="#def_tag_object">tag objects</a>) are stored in <tt>$GIT_DIR/refs/tags/</tt>. A\r
An <a href="#def_object">object</a> containing a <a href="#def_ref">ref</a> pointing to\r
another object, which can contain a message just like a\r
<a href="#def_commit_object">commit object</a>. It can also contain a (PGP)\r
- signature, in which case it is called a "signed <a href="#def_tag_object">tag object</a>".\r
+ signature, in which case it is called a "signed tag object".\r
</p>\r
</dd>\r
<dt>\r
</dt>\r
<dd>\r
<p>\r
- Either a <a href="#def_working_tree">working tree</a>, or a <a href="#def_tree_object">tree object</a> together with the dependent blob and tree objects\r
+ Either a <a href="#def_working_tree">working tree</a>, or a <a href="#def_tree_object">tree object</a> together with the dependent <a href="#def_blob_object">blob</a> and tree objects\r
(i.e. a stored representation of a working tree).\r
</p>\r
</dd>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 19-May-2007 04:19:47 UTC\r
+Last updated 27-May-2007 04:28:37 UTC\r
</div>\r
</div>\r
</body>\r
A bare repository is normally an appropriately
named <<def_directory,directory>> with a `.git` suffix that does not
have a locally checked-out copy of any of the files under
- <<def_revision,revision>> control. That is, all of the `git`
+ revision control. That is, all of the `git`
administrative and control files that would normally be present in the
hidden `.git` sub-directory are directly present in the
`repository.git` directory instead,
[[def_chain]]chain::
A list of objects, where each <<def_object,object>> in the list contains
a reference to its successor (for example, the successor of a
- <<def_commit,commit>> could be one of its parents).
+ <<def_commit,commit>> could be one of its <<def_parent,parents>>).
[[def_changeset]]changeset::
BitKeeper/cvsps speak for "<<def_commit,commit>>". Since git does not
[[def_commit_object]]commit object::
An <<def_object,object>> which contains the information about a
- particular <<def_revision,revision>>, such as parents, committer,
+ particular <<def_revision,revision>>, such as <<def_parent,parents>>, committer,
author, date and the <<def_tree_object,tree object>> which corresponds
to the top <<def_directory,directory>> of the stored
- <<def_revision,revision>>.
+ revision.
[[def_core_git]]core git::
Fundamental data structures and utilities of git. Exposes only limited
[[def_detached_HEAD]]detached HEAD::
Normally the <<def_HEAD,HEAD>> stores the name of a
- <<def_branch,branch>>. However, git also allows you to check
- out an arbitrary commit that isn't necessarily the tip of any
+ <<def_branch,branch>>. However, git also allows you to <<def_checkout,check out>>
+ an arbitrary <<def_commit,commit>> that isn't necessarily the tip of any
particular branch. In this case HEAD is said to be "detached".
[[def_dircache]]dircache::
- You are *waaaaay* behind.
+ You are *waaaaay* behind. See <<def_index,index>>.
[[def_directory]]directory::
The list you get with "ls" :-)
[[def_dirty]]dirty::
A <<def_working_tree,working tree>> is said to be "dirty" if
- it contains modifications which have not been committed to the current
+ it contains modifications which have not been <<def_commit,committed>> to the current
<<def_branch,branch>>.
[[def_ent]]ent::
`http://en.wikipedia.org/wiki/Ent_(Middle-earth)` for an in-depth
explanation. Avoid this term, not to confuse people.
+[[def_evil_merge]]evil merge::
+ An evil merge is a <<def_merge,merge>> that introduces changes that
+ do not appear in any <<def_parent,parent>>.
+
[[def_fast_forward]]fast forward::
A fast-forward is a special type of <<def_merge,merge>> where you have a
<<def_revision,revision>> and you are "merging" another
[[def_grafts]]grafts::
Grafts enables two otherwise different lines of development to be joined
together by recording fake ancestry information for commits. This way
- you can make git pretend the set of parents a <<def_commit,commit>> has
+ you can make git pretend the set of <<def_parent,parents>> a <<def_commit,commit>> has
is different from what was recorded when the commit was
created. Configured via the `.git/info/grafts` file.
In git's context, synonym to <<def_object_name,object name>>.
[[def_head]]head::
- A named reference to the <<def_commit,commit>> at the tip of a
+ A <<def_ref,named reference>> to the <<def_commit,commit>> at the tip of a
<<def_branch,branch>>. Heads are stored in
`$GIT_DIR/refs/heads/`, except when using packed refs. (See
gitlink:git-pack-refs[1].)
[[def_HEAD]]HEAD::
- The current branch. In more detail: Your <<def_working_tree,
+ The current <<def_branch,branch>>. In more detail: Your <<def_working_tree,
working tree>> is normally derived from the state of the tree
referred to by HEAD. HEAD is a reference to one of the
<<def_head,heads>> in your repository, except when using a
checking. Typically, the hooks allow for a command to be pre-verified
and potentially aborted, and allow for a post-notification after the
operation is done. The hook scripts are found in the
- `$GIT_DIR/hooks/` <<def_directory,directory>>, and are enabled by simply
+ `$GIT_DIR/hooks/` directory, and are enabled by simply
making them executable.
[[def_index]]index::
A collection of files with stat information, whose contents are stored
- as objects. The index is a stored version of your working
- <<def_tree,tree>>. Truth be told, it can also contain a second, and even
- a third version of a <<def_working_tree,working tree>>, which are used
- when merging.
+ as objects. The index is a stored version of your
+ <<def_working_tree,working tree>>. Truth be told, it can also contain a second, and even
+ a third version of a working tree, which are used
+ when <<def_merge,merging>>.
[[def_index_entry]]index entry::
The information regarding a particular file, stored in the
describing the type of an <<def_object,object>>.
[[def_octopus]]octopus::
- To <<def_merge,merge>> more than two branches. Also denotes an
+ To <<def_merge,merge>> more than two <<def_branch,branches>>. Also denotes an
intelligent predator.
[[def_origin]]origin::
The default upstream <<def_repository,repository>>. Most projects have
at least one upstream project which they track. By default
'origin' is used for that purpose. New upstream updates
- will be fetched into remote tracking branches named
+ will be fetched into remote <<def_tracking_branch,tracking branches>> named
origin/name-of-upstream-branch, which you can see using
- "git <<def_branch,branch>> -r".
+ "`git branch -r`".
[[def_pack]]pack::
A set of objects which have been compressed into one file (to save space
`$GIT_DIR/refs/`.
[[def_refspec]]refspec::
- A <<def_refspec,refspec>> is used by <<def_fetch,fetch>> and
+ A "refspec" is used by <<def_fetch,fetch>> and
<<def_push,push>> to describe the mapping between remote
<<def_ref,ref>> and local ref. They are combined with a colon in
the format <src>:<dst>, preceded by an optional plus sign, +.
gitlink:git-push[1]
[[def_repository]]repository::
- A collection of refs together with an
+ A collection of <<def_ref,refs>> together with an
<<def_object_database,object database>> containing all objects
which are <<def_reachable,reachable>> from the refs, possibly
- accompanied by meta data from one or more porcelains. A
- repository can share an object database with other repositories.
+ accompanied by meta data from one or more <<def_porcelain,porcelains>>. A
+ repository can share an object database with other repositories
+ via <<def_alternate_object_database,alternates mechanism>>.
[[def_resolve]]resolve::
The action of fixing up manually what a failed automatic
Synonym for <<def_object_name,object name>>.
[[def_shallow_repository]]shallow repository::
- A shallow repository has an incomplete
- history some of whose commits have parents cauterized away (in other
+ A shallow <<def_repository,repository>> has an incomplete
+ history some of whose <<def_commit,commits>> have <<def_parent,parents>> cauterized away (in other
words, git is told to pretend that these commits do not have the
parents, even though they are recorded in the <<def_commit_object,commit
object>>). This is sometimes useful when you are interested only in the
command.
[[def_tag]]tag::
- A <<def_ref,ref>> pointing to a tag or
+ A <<def_ref,ref>> pointing to a <<def_tag_object,tag>> or
<<def_commit_object,commit object>>. In contrast to a <<def_head,head>>,
a tag is not changed by a <<def_commit,commit>>. Tags (not
<<def_tag_object,tag objects>>) are stored in `$GIT_DIR/refs/tags/`. A
An <<def_object,object>> containing a <<def_ref,ref>> pointing to
another object, which can contain a message just like a
<<def_commit_object,commit object>>. It can also contain a (PGP)
- signature, in which case it is called a "signed <<def_tag_object,tag
- object>>".
+ signature, in which case it is called a "signed tag object".
[[def_topic_branch]]topic branch::
A regular git <<def_branch,branch>> that is used by a developer to
[[def_tree]]tree::
Either a <<def_working_tree,working tree>>, or a <<def_tree_object,tree
- object>> together with the dependent blob and tree objects
+ object>> together with the dependent <<def_blob_object,blob>> and tree objects
(i.e. a stored representation of a working tree).
[[def_tree_object]]tree object::
A bare repository is normally an appropriately
named <a href="#def_directory">directory</a> with a <code class="literal">.git</code> suffix that does not
have a locally checked-out copy of any of the files under
- <a href="#def_revision">revision</a> control. That is, all of the <code class="literal">git</code>
+ revision control. That is, all of the <code class="literal">git</code>
administrative and control files that would normally be present in the
hidden <code class="literal">.git</code> sub-directory are directly present in the
<code class="literal">repository.git</code> directory instead,
</span></dt><dd>
A list of objects, where each <a href="#def_object">object</a> in the list contains
a reference to its successor (for example, the successor of a
- <a href="#def_commit">commit</a> could be one of its parents).
+ <a href="#def_commit">commit</a> could be one of its <a href="#def_parent">parents</a>).
</dd><dt><span class="term">
<a name="def_changeset"></a>changeset
</span></dt><dd>
<a name="def_commit_object"></a>commit object
</span></dt><dd>
An <a href="#def_object">object</a> which contains the information about a
- particular <a href="#def_revision">revision</a>, such as parents, committer,
+ particular <a href="#def_revision">revision</a>, such as <a href="#def_parent">parents</a>, committer,
author, date and the <a href="#def_tree_object">tree object</a> which corresponds
to the top <a href="#def_directory">directory</a> of the stored
- <a href="#def_revision">revision</a>.
+ revision.
</dd><dt><span class="term">
<a name="def_core_git"></a>core git
</span></dt><dd>
<a name="def_detached_HEAD"></a>detached HEAD
</span></dt><dd>
Normally the <a href="#def_HEAD">HEAD</a> stores the name of a
- <a href="#def_branch">branch</a>. However, git also allows you to check
- out an arbitrary commit that isn't necessarily the tip of any
+ <a href="#def_branch">branch</a>. However, git also allows you to <a href="#def_checkout">check out</a>
+ an arbitrary <a href="#def_commit">commit</a> that isn't necessarily the tip of any
particular branch. In this case HEAD is said to be "detached".
</dd><dt><span class="term">
<a name="def_dircache"></a>dircache
</span></dt><dd>
- You are <span class="strong"><strong>waaaaay</strong></span> behind.
+ You are <span class="strong"><strong>waaaaay</strong></span> behind. See <a href="#def_index">index</a>.
</dd><dt><span class="term">
<a name="def_directory"></a>directory
</span></dt><dd>
<a name="def_dirty"></a>dirty
</span></dt><dd>
A <a href="#def_working_tree">working tree</a> is said to be "dirty" if
- it contains modifications which have not been committed to the current
+ it contains modifications which have not been <a href="#def_commit">committed</a> to the current
<a href="#def_branch">branch</a>.
</dd><dt><span class="term">
<a name="def_ent"></a>ent
<code class="literal">http://en.wikipedia.org/wiki/Ent_(Middle-earth)</code> for an in-depth
explanation. Avoid this term, not to confuse people.
</dd><dt><span class="term">
+<a name="def_evil_merge"></a>evil merge
+</span></dt><dd>
+ An evil merge is a <a href="#def_merge">merge</a> that introduces changes that
+ do not appear in any <a href="#def_parent">parent</a>.
+</dd><dt><span class="term">
<a name="def_fast_forward"></a>fast forward
</span></dt><dd>
A fast-forward is a special type of <a href="#def_merge">merge</a> where you have a
</span></dt><dd>
Grafts enables two otherwise different lines of development to be joined
together by recording fake ancestry information for commits. This way
- you can make git pretend the set of
parents a <a href="#def_commit">commit</a> has
+ you can make git pretend the set of
<a href="#def_parent">parents</a> a <a href="#def_commit">commit</a> has
is different from what was recorded when the commit was
created. Configured via the <code class="literal">.git/info/grafts</code> file.
</dd><dt><span class="term">
</dd><dt><span class="term">
<a name="def_head"></a>head
</span></dt><dd>
- A
named reference to the <a href="#def_commit">commit</a> at the tip of a
+ A
<a href="#def_ref">named reference</a> to the <a href="#def_commit">commit</a> at the tip of a
<a href="#def_branch">branch</a>. Heads are stored in
<code class="literal">$GIT_DIR/refs/heads/</code>, except when using packed refs. (See
<a href="git-pack-refs.html" target="_top">git-pack-refs(1)</a>.)
</dd><dt><span class="term">
<a name="def_HEAD"></a>HEAD
</span></dt><dd>
- The current
branch. In more detail: Your <a href="#def_working_tree">working tree</a> is normally derived from the state of the tree
+ The current
<a href="#def_branch">branch</a>. In more detail: Your <a href="#def_working_tree">working tree</a> is normally derived from the state of the tree
referred to by HEAD. HEAD is a reference to one of the
<a href="#def_head">heads</a> in your repository, except when using a
<a href="#def_detached_HEAD">detached HEAD</a>, in which case it may
checking. Typically, the hooks allow for a command to be pre-verified
and potentially aborted, and allow for a post-notification after the
operation is done. The hook scripts are found in the
- <code class="literal">$GIT_DIR/hooks/</code> <a href="#def_directory">directory</a>, and are enabled by simply
+ <code class="literal">$GIT_DIR/hooks/</code> directory, and are enabled by simply
making them executable.
</dd><dt><span class="term">
<a name="def_index"></a>index
</span></dt><dd>
A collection of files with stat information, whose contents are stored
- as objects. The index is a stored version of your working
- <a href="#def_tree">tree</a>. Truth be told, it can also contain a second, and even
- a third version of a <a href="#def_working_tree">working tree</a>, which are used
- when merging.
+ as objects. The index is a stored version of your
+ <a href="#def_working_tree">working tree</a>. Truth be told, it can also contain a second, and even
+ a third version of a working tree, which are used
+ when <a href="#def_merge">merging</a>.
</dd><dt><span class="term">
<a name="def_index_entry"></a>index entry
</span></dt><dd>
</dd><dt><span class="term">
<a name="def_octopus"></a>octopus
</span></dt><dd>
- To <a href="#def_merge">merge</a> more than two branches. Also denotes an
+ To <a href="#def_merge">merge</a> more than two <a href="#def_branch">branches</a>. Also denotes an
intelligent predator.
</dd><dt><span class="term">
<a name="def_origin"></a>origin
The default upstream <a href="#def_repository">repository</a>. Most projects have
at least one upstream project which they track. By default
<span class="emphasis"><em>origin</em></span> is used for that purpose. New upstream updates
- will be fetched into remote tracking branches named
+ will be fetched into remote <a href="#def_tracking_branch">tracking branches</a> named
origin/name-of-upstream-branch, which you can see using
- "git <a href="#def_branch">branch</a> -r".
+ "<code class="literal">git branch -r</code>".
</dd><dt><span class="term">
<a name="def_pack"></a>pack
</span></dt><dd>
</dd><dt><span class="term">
<a name="def_refspec"></a>refspec
</span></dt><dd>
- A
<a href="#def_refspec">refspec</a> is used by <a href="#def_fetch">fetch</a> and
+ A
"refspec" is used by <a href="#def_fetch">fetch</a> and
<a href="#def_push">push</a> to describe the mapping between remote
<a href="#def_ref">ref</a> and local ref. They are combined with a colon in
the format <src>:<dst>, preceded by an optional plus sign, +.
</dd><dt><span class="term">
<a name="def_repository"></a>repository
</span></dt><dd>
- A collection of refs together with an
+ A collection of <a href="#def_ref">refs</a> together with an
<a href="#def_object_database">object database</a> containing all objects
which are <a href="#def_reachable">reachable</a> from the refs, possibly
- accompanied by meta data from one or more porcelains. A
- repository can share an object database with other repositories.
+ accompanied by meta data from one or more <a href="#def_porcelain">porcelains</a>. A
+ repository can share an object database with other repositories
+ via <a href="#def_alternate_object_database">alternates mechanism</a>.
</dd><dt><span class="term">
<a name="def_resolve"></a>resolve
</span></dt><dd>
</dd><dt><span class="term">
<a name="def_shallow_repository"></a>shallow repository
</span></dt><dd>
- A shallow repository has an incomplete
- history some of whose commits have parents cauterized away (in other
+ A shallow <a href="#def_repository">repository</a> has an incomplete
+ history some of whose <a href="#def_commit">commits</a> have <a href="#def_parent">parents</a> cauterized away (in other
words, git is told to pretend that these commits do not have the
parents, even though they are recorded in the <a href="#def_commit_object">commit object</a>). This is sometimes useful when you are interested only in the
recent history of a project even though the real history recorded in the
</dd><dt><span class="term">
<a name="def_tag"></a>tag
</span></dt><dd>
- A <a href="#def_ref">ref</a> pointing to a tag or
+ A <a href="#def_ref">ref</a> pointing to a <a href="#def_tag_object">tag</a> or
<a href="#def_commit_object">commit object</a>. In contrast to a <a href="#def_head">head</a>,
a tag is not changed by a <a href="#def_commit">commit</a>. Tags (not
<a href="#def_tag_object">tag objects</a>) are stored in <code class="literal">$GIT_DIR/refs/tags/</code>. A
An <a href="#def_object">object</a> containing a <a href="#def_ref">ref</a> pointing to
another object, which can contain a message just like a
<a href="#def_commit_object">commit object</a>. It can also contain a (PGP)
- signature, in which case it is called a "signed <a href="#def_tag_object">tag object</a>".
+ signature, in which case it is called a "signed tag object".
</dd><dt><span class="term">
<a name="def_topic_branch"></a>topic branch
</span></dt><dd>
</dd><dt><span class="term">
<a name="def_tree"></a>tree
</span></dt><dd>
- Either a <a href="#def_working_tree">working tree</a>, or a <a href="#def_tree_object">tree object</a> together with the dependent blob and tree objects
+ Either a <a href="#def_working_tree">working tree</a>, or a <a href="#def_tree_object">tree object</a> together with the dependent <a href="#def_blob_object">blob</a> and tree objects
(i.e. a stored representation of a working tree).
</dd><dt><span class="term">
<a name="def_tree_object"></a>tree object
projects / git.git / commitdiff