Autogenerated HTML docs for v1.3.2-g45f7
[git.git] / glossary.html
index 00f2633..0c45a4f 100644 (file)
@@ -3,7 +3,7 @@
 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">\r
 <head>\r
 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />\r
-<meta name="generator" content="AsciiDoc 7.0.1" />\r
+<meta name="generator" content="AsciiDoc 7.0.2" />\r
 <style type="text/css">\r
 /* Debug borders */\r
 p, li, dt, dd, div, pre, h1, h2, h3, h4, h5, h6 {\r
@@ -276,6 +276,22 @@ div.exampleblock-content {
 </p>\r
 </dd>\r
 <dt>\r
+<a id="ref_bare_repository"></a>bare repository\r
+</dt>\r
+<dd>\r
+<p>\r
+        A <a href="#ref_bare_repository">bare repository</a> is normally an appropriately\r
+        named <a href="#ref_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="#ref_revision">revision</a> 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-<a href="#ref_directory">directory</a> are directly present in\r
+        the <tt><a href="#ref_repository">repository</a>.git</tt> <a href="#ref_directory">directory</a>\r
+        instead, and no other files are present and checked out. Usually\r
+        publishers of public repositories make bare repositories available.\r
+</p>\r
+</dd>\r
+<dt>\r
 <a id="ref_blob_object"></a>blob object\r
 </dt>\r
 <dd>\r
@@ -333,13 +349,26 @@ div.exampleblock-content {
 </p>\r
 </dd>\r
 <dt>\r
+<a id="ref_cherry-picking"></a>cherry-picking\r
+</dt>\r
+<dd>\r
+<p>\r
+        In <a href="#ref_SCM">SCM</a> jargon, "cherry pick" means to choose a subset of\r
+        changes out of a series of changes (typically commits) and record them\r
+        as a new series of changes on top of different codebase. In GIT, this is\r
+        performed by "git cherry-pick" command to extract the change introduced\r
+        by an existing <a href="#ref_commit">commit</a> and to record it based on the tip\r
+        of the current <a href="#ref_branch">branch</a> as a new <a href="#ref_commit">commit</a>.\r
+</p>\r
+</dd>\r
+<dt>\r
 <a id="ref_clean"></a>clean\r
 </dt>\r
 <dd>\r
 <p>\r
         A <a href="#ref_working_tree">working tree</a> is <a href="#ref_clean">clean</a>, if it\r
         corresponds to the <a href="#ref_revision">revision</a> referenced by the current\r
-        <a href="#ref_head">head</a>.\r
+        <a href="#ref_head">head</a>. Also see "<a href="#ref_dirty">dirty</a>".\r
 </p>\r
 </dd>\r
 <dt>\r
@@ -423,6 +452,21 @@ div.exampleblock-content {
 </p>\r
 </dd>\r
 <dt>\r
+<a id="ref_fast_forward"></a>fast forward\r
+</dt>\r
+<dd>\r
+<p>\r
+        A fast-forward is a special type of <a href="#ref_merge">merge</a> where you have a\r
+        <a href="#ref_revision">revision</a> and you are "merging" another\r
+        <a href="#ref_branch">branch</a>'s changes that happen to be a descendant of what\r
+        you have. In such these cases, you do not make a new <a href="#ref_merge">merge</a>\r
+        <a href="#ref_commit">commit</a> but instead just update to his\r
+        <a href="#ref_revision">revision</a>. This will happen frequently on a\r
+        <a href="#ref_tracking_branch">tracking branch</a> of a remote\r
+        <a href="#ref_repository">repository</a>.\r
+</p>\r
+</dd>\r
+<dt>\r
 <a id="ref_fetch"></a>fetch\r
 </dt>\r
 <dd>\r
@@ -480,6 +524,20 @@ div.exampleblock-content {
 </p>\r
 </dd>\r
 <dt>\r
+<a id="ref_hook"></a>hook\r
+</dt>\r
+<dd>\r
+<p>\r
+        During the normal execution of several git commands, call-outs are made\r
+        to optional scripts that allow a developer to add functionality or\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 <a href="#ref_hook">hook</a> scripts are found in the\r
+        <tt>$GIT_DIR/hooks/</tt> <a href="#ref_directory">directory</a>, and are enabled by simply\r
+        making them executable.\r
+</p>\r
+</dd>\r
+<dt>\r
 <a id="ref_index"></a>index\r
 </dt>\r
 <dd>\r
@@ -507,11 +565,11 @@ div.exampleblock-content {
 </dt>\r
 <dd>\r
 <p>\r
-        The default <a href="#ref_branch">branch</a>. Whenever you create a git\r
+        The default development <a href="#ref_branch">branch</a>. Whenever you create a git\r
         <a href="#ref_repository">repository</a>, a <a href="#ref_branch">branch</a> named\r
         "<a href="#ref_master">master</a>" is created, and becomes the active\r
         <a href="#ref_branch">branch</a>. In most cases, this contains the local\r
-        development.\r
+        development, though that is purely conventional and not required.\r
 </p>\r
 </dd>\r
 <dt>\r
@@ -580,11 +638,11 @@ div.exampleblock-content {
 </dt>\r
 <dd>\r
 <p>\r
-        The default upstream <a href="#ref_branch">branch</a>. Most projects have one\r
-        upstream project which they track, and by default\r
-        <em><a href="#ref_origin">origin</a></em> is used for that purpose. New updates from\r
-        upstream will be fetched into this <a href="#ref_branch">branch</a>; you should\r
-        never <a href="#ref_commit">commit</a> to it yourself.\r
+        The default upstream <a href="#ref_tracking_branch">tracking branch</a>. Most\r
+        projects have at least one upstream project which they track. By default\r
+        <em><a href="#ref_origin">origin</a></em> is used for that purpose. New upstream updates\r
+        will be fetched into this <a href="#ref_branch">branch</a>; you should never\r
+        <a href="#ref_commit">commit</a> to it yourself.\r
 </p>\r
 </dd>\r
 <dt>\r
@@ -617,6 +675,18 @@ div.exampleblock-content {
 </p>\r
 </dd>\r
 <dt>\r
+<a id="ref_pickaxe"></a>pickaxe\r
+</dt>\r
+<dd>\r
+<p>\r
+        The term <a href="#ref_pickaxe">pickaxe</a> refers to an option to the diffcore\r
+        routines that help select changes that add or delete a given text\r
+        string. With the &#8212;<a href="#ref_pickaxe">pickaxe</a>-all option, it can be used to\r
+        view the full <a href="#ref_changeset">changeset</a> that introduced or removed,\r
+        say, a particular line of text. See <a href="git-diff.html">git-diff(1)</a>.\r
+</p>\r
+</dd>\r
+<dt>\r
 <a id="ref_plumbing"></a>plumbing\r
 </dt>\r
 <dd>\r
@@ -687,12 +757,32 @@ div.exampleblock-content {
 </dt>\r
 <dd>\r
 <p>\r
-        A 40-byte hex representation of a <a href="#ref_SHA1">SHA1</a> pointing to a\r
-        particular <a href="#ref_object">object</a>. These may be stored in\r
+        A 40-byte hex representation of a <a href="#ref_SHA1">SHA1</a> or a name that\r
+        denotes a particular <a href="#ref_object">object</a>. These may be stored in\r
         <tt>$GIT_DIR/refs/</tt>.\r
 </p>\r
 </dd>\r
 <dt>\r
+<a id="ref_refspec"></a>refspec\r
+</dt>\r
+<dd>\r
+<p>\r
+        A <a href="#ref_refspec">refspec</a> is used by <a href="#ref_fetch">fetch</a> and\r
+        <a href="#ref_push">push</a> to describe the mapping between remote <a href="#ref_ref">ref</a>\r
+        and local <a href="#ref_ref">ref</a>. They are combined with a colon in the format\r
+        &lt;src&gt;:&lt;dst&gt;, preceded by an optional plus sign, +. For example: <tt>git\r
+        <a href="#ref_fetch">fetch</a> $URL\r
+        refs/heads/<a href="#ref_master">master</a>:refs/heads/<a href="#ref_origin">origin</a></tt> means\r
+        "grab the <a href="#ref_master">master</a> <a href="#ref_branch">branch</a> <a href="#ref_head">head</a>\r
+        from the $URL and store it as my <a href="#ref_origin">origin</a>\r
+        <a href="#ref_branch">branch</a> <a href="#ref_head">head</a>". And <tt>git <a href="#ref_push">push</a>\r
+        $URL refs/heads/<a href="#ref_master">master</a>:refs/heads/to-upstream</tt> means\r
+        "publish my <a href="#ref_master">master</a> <a href="#ref_branch">branch</a>\r
+        <a href="#ref_head">head</a> as to-upstream <a href="#ref_master">master</a> <a href="#ref_head">head</a>\r
+        at $URL". See also <a href="git-push.html">git-push(1)</a>\r
+</p>\r
+</dd>\r
+<dt>\r
 <a id="ref_repository"></a>repository\r
 </dt>\r
 <dd>\r
@@ -774,6 +864,30 @@ div.exampleblock-content {
 </p>\r
 </dd>\r
 <dt>\r
+<a id="ref_topic_branch"></a>topic branch\r
+</dt>\r
+<dd>\r
+<p>\r
+        A regular git <a href="#ref_branch">branch</a> that is used by a developer to\r
+        identify a conceptual line of development. Since branches are very easy\r
+        and inexpensive, it is often desirable to have several small branches\r
+        that each contain very well defined concepts or small incremental yet\r
+        related changes.\r
+</p>\r
+</dd>\r
+<dt>\r
+<a id="ref_tracking_branch"></a>tracking branch\r
+</dt>\r
+<dd>\r
+<p>\r
+        A regular git <a href="#ref_branch">branch</a> that is used to follow changes from\r
+        another <a href="#ref_repository">repository</a>. A <a href="#ref_tracking_branch">tracking         branch</a> should not contain direct modifications or have local commits\r
+        made to it. A <a href="#ref_tracking_branch">tracking branch</a> can usually be\r
+        identified as the right-hand-side <a href="#ref_ref">ref</a> in a Pull:\r
+        <a href="#ref_refspec">refspec</a>.\r
+</p>\r
+</dd>\r
+<dt>\r
 <a id="ref_tree"></a>tree\r
 </dt>\r
 <dd>\r
@@ -824,7 +938,7 @@ the git-list &lt;git@vger.kernel.org&gt;.</p>
 </div>\r
 <div id="footer">\r
 <div id="footer-text">\r
-Last updated 10-Jan-2006 16:53:50 PDT\r
+Last updated 04-May-2006 08:01:37 UTC\r
 </div>\r
 </div>\r
 </body>\r