Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse files

Autogenerated HTML docs for v1.8.4-357-g8d83

  • Loading branch information...
commit e6f28d0b6c239f15760194c8b12afdaa1a7bdd34 1 parent 0e0e0d2
Junio C Hamano authored
Showing with 403 additions and 280 deletions.
  1. +1 −1  RelNotes/1.7.11.2.txt
  2. +22 −0 RelNotes/1.8.5.txt
  3. +4 −4 config.txt
  4. +2 −2 everyday.html
  5. +1 −1  everyday.txt
  6. +2 −2 git-cat-file.html
  7. +1 −1  git-cat-file.txt
  8. +4 −4 git-config.html
  9. +2 −2 git-credential.html
  10. +1 −1  git-credential.txt
  11. +8 −8 git-describe.html
  12. +7 −7 git-describe.txt
  13. +14 −4 git-diff.html
  14. +9 −4 git-diff.txt
  15. +14 −14 git-fast-import.html
  16. +13 −13 git-fast-import.txt
  17. +2 −2 git-merge-tree.html
  18. +1 −1  git-merge-tree.txt
  19. +2 −2 git-name-rev.html
  20. +1 −1  git-name-rev.txt
  21. +2 −2 git-push.html
  22. +1 −1  git-push.txt
  23. +3 −3 git-rebase.html
  24. +2 −2 git-rebase.txt
  25. +8 −4 git-rev-parse.html
  26. +2 −2 git-revert.html
  27. +1 −1  git-revert.txt
  28. +2 −2 gitcli.html
  29. +1 −1  gitcli.txt
  30. +2 −2 gitcvs-migration.html
  31. +1 −1  gitcvs-migration.txt
  32. +42 −6 gitglossary.html
  33. +8 −4 gitrevisions.html
  34. +39 −8 glossary-content.txt
  35. +2 −2 howto/revert-branch-rebase.html
  36. +1 −1  howto/revert-branch-rebase.txt
  37. +8 −4 revisions.txt
  38. +2 −2 technical/http-protocol.txt
  39. +100 −77 user-manual.html
  40. +65 −81 user-manual.txt
2  RelNotes/1.7.11.2.txt
View
@@ -31,7 +31,7 @@ Fixes since v1.7.11.1
* "git diff --no-index" did not work with pagers correctly.
* "git diff COPYING HEAD:COPYING" gave a nonsense error message that
- claimed that the treeish HEAD did not have COPYING in it.
+ claimed that the tree-ish HEAD did not have COPYING in it.
* When "git log" gets "--simplify-merges/by-decoration" together with
"--first-parent", the combination of these options makes the
22 RelNotes/1.8.5.txt
View
@@ -48,6 +48,10 @@ Updates since v1.8.4
Foreign interfaces, subsystems and ports.
+ * On MacOS X, we detected if the filesystem needs the "pre-composed
+ unicode strings" workaround, but did not automatically enable it.
+ Now we do.
+
* remote-hg remote helper misbehaved when interacting with a local Hg
repository relative to the home directory, e.g. "clone hg::~/there".
@@ -63,6 +67,12 @@ Foreign interfaces, subsystems and ports.
UI, Workflows & Features
+ * Earlier we started rejecting an attempt to add 0{40} object name to
+ the index and to tree objects, but it sometimes is necessary to
+ allow so to be able to use tools like filter-branch to correct such
+ broken tree objects. "filter-branch" can again be used to to do
+ so.
+
* "git config" did not provide a way to set or access numbers larger
than a native "int" on the platform; it now provides 64-bit signed
integers on all platforms.
@@ -155,6 +165,18 @@ Unless otherwise noted, all the fixes since v1.8.4 in the maintenance
track are contained in this release (see release notes to them for
details).
+ * When an object is not found after checking the packfiles and then
+ loose object directory, read_sha1_file() re-checks the packfiles to
+ prevent racing with a concurrent repacker; teach the same logic to
+ has_sha1_file().
+ (merge 45e8a74 jk/has-sha1-file-retry-packed later to maint).
+
+ * "git commit --author=$name", when $name is not in the canonical
+ "A. U. Thor <au.thor@example.xz>" format, looks for a matching name
+ from existing history, but did not consult mailmap to grab the
+ preferred author name.
+ (merge ea16794 ap/commit-author-mailmap later to maint).
+
* "git ls-files -k" needs to crawl only the part of the working tree
that may overlap the paths in the index to find killed files, but
shared code with the logic to find all the untracked files, which
8 config.txt
View
@@ -170,8 +170,8 @@ advice.*::
pushNeedsForce::
Shown when linkgit:git-push[1] rejects an update that
tries to overwrite a remote ref that points at an
- object that is not a committish, or make the remote
- ref point at an object that is not a committish.
+ object that is not a commit-ish, or make the remote
+ ref point at an object that is not a commit-ish.
statusHints::
Show directions on how to proceed from the current
state in the output of linkgit:git-status[1], in
@@ -789,8 +789,8 @@ browser.<tool>.path::
working repository in gitweb (see linkgit:git-instaweb[1]).
clean.requireForce::
- A boolean to make git-clean do nothing unless given -f
- or -n. Defaults to true.
+ A boolean to make git-clean do nothing unless given -f,
+ -i or -n. Defaults to true.
color.branch::
A boolean to enable/disable color in the output of
4 everyday.html
View
@@ -1303,7 +1303,7 @@ <h2 id="_repository_administration_a_id_repository_administration_a">Repository
</p>
</li>
</ul></div>
-<div class="paragraph"><p><a href="howto/update-hook-example.txt">update hook howto</a> has a good
+<div class="paragraph"><p><a href="howto/update-hook-example.html">update hook howto</a> has a good
example of managing a shared central repository.</p></div>
<div class="sect2">
<h3 id="_examples_4">Examples</h3>
@@ -1469,7 +1469,7 @@ <h3 id="_examples_4">Examples</h3>
<div id="footnotes"><hr /></div>
<div id="footer">
<div id="footer-text">
-Last updated 2013-08-20 08:40:27 PDT
+Last updated 2013-09-17 14:33:14 PDT
</div>
</div>
</body>
2  everyday.txt
View
@@ -304,7 +304,7 @@ and maintain access to the repository by developers.
* linkgit:git-shell[1] can be used as a 'restricted login shell'
for shared central repository users.
-link:howto/update-hook-example.txt[update hook howto] has a good
+link:howto/update-hook-example.html[update hook howto] has a good
example of managing a shared central repository.
4 git-cat-file.html
View
@@ -831,7 +831,7 @@ <h2 id="_options">OPTIONS</h2>
<dd>
<p>
Show the content as transformed by a textconv filter. In this case,
- &lt;object&gt; has be of the form &lt;treeish&gt;:&lt;path&gt;, or :&lt;path&gt; in order
+ &lt;object&gt; has be of the form &lt;tree-ish&gt;:&lt;path&gt;, or :&lt;path&gt; in order
to apply the filter to the content recorded in the index at &lt;path&gt;.
</p>
</dd>
@@ -981,7 +981,7 @@ <h2 id="_git">GIT</h2>
<div id="footnotes"><hr /></div>
<div id="footer">
<div id="footer-text">
-Last updated 2013-09-09 15:34:20 PDT
+Last updated 2013-09-17 14:33:14 PDT
</div>
</div>
</body>
2  git-cat-file.txt
View
@@ -54,7 +54,7 @@ OPTIONS
--textconv::
Show the content as transformed by a textconv filter. In this case,
- <object> has be of the form <treeish>:<path>, or :<path> in order
+ <object> has be of the form <tree-ish>:<path>, or :<path> in order
to apply the filter to the content recorded in the index at <path>.
--batch::
8 git-config.html
View
@@ -1538,8 +1538,8 @@ <h3 id="_variables">Variables</h3>
<p>
Shown when <a href="git-push.html">git-push(1)</a> rejects an update that
tries to overwrite a remote ref that points at an
- object that is not a committish, or make the remote
- ref point at an object that is not a committish.
+ object that is not a commit-ish, or make the remote
+ ref point at an object that is not a commit-ish.
</p>
</dd>
<dt class="hdlist1">
@@ -2490,8 +2490,8 @@ <h3 id="_variables">Variables</h3>
</dt>
<dd>
<p>
- A boolean to make git-clean do nothing unless given -f
- or -n. Defaults to true.
+ A boolean to make git-clean do nothing unless given -f,
+ -i or -n. Defaults to true.
</p>
</dd>
<dt class="hdlist1">
4 git-credential.html
View
@@ -760,7 +760,7 @@ <h2 id="_description">DESCRIPTION</h2>
interface to scripts which may want to retrieve, store, or prompt for
credentials in the same manner as Git. The design of this scriptable
interface models the internal C API; see
-<a href="technical/api-credentials.txt">the Git credential API</a> for more
+<a href="technical/api-credentials.html">the Git credential API</a> for more
background on the concepts.</p></div>
<div class="paragraph"><p>git-credential takes an "action" option on the command-line (one of
<code>fill</code>, <code>approve</code>, or <code>reject</code>) and reads a credential description
@@ -934,7 +934,7 @@ <h2 id="IOFMT">INPUT/OUTPUT FORMAT</h2>
<div id="footnotes"><hr /></div>
<div id="footer">
<div id="footer-text">
-Last updated 2013-08-20 08:40:27 PDT
+Last updated 2013-09-17 14:33:14 PDT
</div>
</div>
</body>
2  git-credential.txt
View
@@ -20,7 +20,7 @@ usernames and passwords. The git-credential command exposes this
interface to scripts which may want to retrieve, store, or prompt for
credentials in the same manner as Git. The design of this scriptable
interface models the internal C API; see
-link:technical/api-credentials.txt[the Git credential API] for more
+link:technical/api-credentials.html[the Git credential API] for more
background on the concepts.
git-credential takes an "action" option on the command-line (one of
16 git-describe.html
View
@@ -746,7 +746,7 @@
<h2 id="_synopsis">SYNOPSIS</h2>
<div class="sectionbody">
<div class="verseblock">
-<pre class="content"><em>git describe</em> [--all] [--tags] [--contains] [--abbrev=&lt;n&gt;] &lt;committish&gt;&#8230;
+<pre class="content"><em>git describe</em> [--all] [--tags] [--contains] [--abbrev=&lt;n&gt;] &lt;commit-ish&gt;&#8230;
<em>git describe</em> [--all] [--tags] [--contains] [--abbrev=&lt;n&gt;] --dirty[=&lt;mark&gt;]</pre>
<div class="attribution">
</div></div>
@@ -770,11 +770,11 @@ <h2 id="_options">OPTIONS</h2>
<div class="sectionbody">
<div class="dlist"><dl>
<dt class="hdlist1">
-&lt;committish&gt;&#8230;
+&lt;commit-ish&gt;&#8230;
</dt>
<dd>
<p>
- Committish object names to describe.
+ Commit-ish object names to describe.
</p>
</dd>
<dt class="hdlist1">
@@ -834,7 +834,7 @@ <h2 id="_options">OPTIONS</h2>
<dd>
<p>
Instead of considering only the 10 most recent tags as
- candidates to describe the input committish consider
+ candidates to describe the input commit-ish consider
up to &lt;n&gt; candidates. Increasing &lt;n&gt; above 10 will take
slightly longer but may produce a more accurate result.
An &lt;n&gt; of 0 will cause only exact matches to be output.
@@ -960,7 +960,7 @@ <h2 id="_examples">EXAMPLES</h2>
<div class="sect1">
<h2 id="_search_strategy">SEARCH STRATEGY</h2>
<div class="sectionbody">
-<div class="paragraph"><p>For each committish supplied, <em>git describe</em> will first look for
+<div class="paragraph"><p>For each commit-ish supplied, <em>git describe</em> will first look for
a tag which tags exactly that commit. Annotated tags will always
be preferred over lightweight tags, and tags with newer dates will
always be preferred over tags with older dates. If an exact match
@@ -968,11 +968,11 @@ <h2 id="_search_strategy">SEARCH STRATEGY</h2>
<div class="paragraph"><p>If an exact match was not found, <em>git describe</em> will walk back
through the commit history to locate an ancestor commit which
has been tagged. The ancestor&#8217;s tag will be output along with an
-abbreviation of the input committish&#8217;s SHA-1. If <em>--first-parent</em> was
+abbreviation of the input commit-ish&#8217;s SHA-1. If <em>--first-parent</em> was
specified then the walk will only consider the first parent of each
commit.</p></div>
<div class="paragraph"><p>If multiple tags were found during the walk then the tag which
-has the fewest commits different from the input committish will be
+has the fewest commits different from the input commit-ish will be
selected and output. Here fewest commits different is defined as
the number of commits which would be shown by <code>git log tag..input</code>
will be the smallest number of commits possible.</p></div>
@@ -988,7 +988,7 @@ <h2 id="_git">GIT</h2>
<div id="footnotes"><hr /></div>
<div id="footer">
<div id="footer-text">
-Last updated 2013-08-20 08:40:27 PDT
+Last updated 2013-09-17 14:33:14 PDT
</div>
</div>
</body>
14 git-describe.txt
View
@@ -9,7 +9,7 @@ git-describe - Show the most recent tag that is reachable from a commit
SYNOPSIS
--------
[verse]
-'git describe' [--all] [--tags] [--contains] [--abbrev=<n>] <committish>...
+'git describe' [--all] [--tags] [--contains] [--abbrev=<n>] <commit-ish>...
'git describe' [--all] [--tags] [--contains] [--abbrev=<n>] --dirty[=<mark>]
DESCRIPTION
@@ -26,8 +26,8 @@ see the -a and -s options to linkgit:git-tag[1].
OPTIONS
-------
-<committish>...::
- Committish object names to describe.
+<commit-ish>...::
+ Commit-ish object names to describe.
--dirty[=<mark>]::
Describe the working tree.
@@ -57,7 +57,7 @@ OPTIONS
--candidates=<n>::
Instead of considering only the 10 most recent tags as
- candidates to describe the input committish consider
+ candidates to describe the input commit-ish consider
up to <n> candidates. Increasing <n> above 10 will take
slightly longer but may produce a more accurate result.
An <n> of 0 will cause only exact matches to be output.
@@ -145,7 +145,7 @@ be sufficient to disambiguate these commits.
SEARCH STRATEGY
---------------
-For each committish supplied, 'git describe' will first look for
+For each commit-ish supplied, 'git describe' will first look for
a tag which tags exactly that commit. Annotated tags will always
be preferred over lightweight tags, and tags with newer dates will
always be preferred over tags with older dates. If an exact match
@@ -154,12 +154,12 @@ is found, its name will be output and searching will stop.
If an exact match was not found, 'git describe' will walk back
through the commit history to locate an ancestor commit which
has been tagged. The ancestor's tag will be output along with an
-abbreviation of the input committish's SHA-1. If '--first-parent' was
+abbreviation of the input commit-ish's SHA-1. If '--first-parent' was
specified then the walk will only consider the first parent of each
commit.
If multiple tags were found during the walk then the tag which
-has the fewest commits different from the input committish will be
+has the fewest commits different from the input commit-ish will be
selected and output. Here fewest commits different is defined as
the number of commits which would be shown by `git log tag..input`
will be the smallest number of commits possible.
18 git-diff.html
View
@@ -773,9 +773,19 @@ <h2 id="_description">DESCRIPTION</h2>
further add to the index but you still haven&#8217;t. You can
stage these changes by using <a href="git-add.html">git-add(1)</a>.
</p>
-<div class="paragraph"><p>If exactly two paths are given and at least one points outside
-the current repository, <em>git diff</em> will compare the two files /
-directories. This behavior can be forced by --no-index.</p></div>
+</dd>
+<dt class="hdlist1">
+<em>git diff</em> --no-index [--options] [--] [&lt;path&gt;&#8230;]
+</dt>
+<dd>
+<p>
+ This form is to compare the given two paths on the
+ filesystem. You can omit the <code>--no-index</code> option when
+ running the command in a working tree controlled by Git and
+ at least one of the paths points outside the working tree,
+ or when running the command outside a working tree
+ controlled by Git.
+</p>
</dd>
<dt class="hdlist1">
<em>git diff</em> [--options] --cached [&lt;commit&gt;] [--] [&lt;path&gt;&#8230;]
@@ -2476,7 +2486,7 @@ <h2 id="_git">GIT</h2>
<div id="footnotes"><hr /></div>
<div id="footer">
<div id="footer-text">
-Last updated 2013-08-20 08:40:27 PDT
+Last updated 2013-09-17 14:33:14 PDT
</div>
</div>
</body>
13 git-diff.txt
View
@@ -28,10 +28,15 @@ two blob objects, or changes between two files on disk.
words, the differences are what you _could_ tell Git to
further add to the index but you still haven't. You can
stage these changes by using linkgit:git-add[1].
-+
-If exactly two paths are given and at least one points outside
-the current repository, 'git diff' will compare the two files /
-directories. This behavior can be forced by --no-index.
+
+'git diff' --no-index [--options] [--] [<path>...]::
+
+ This form is to compare the given two paths on the
+ filesystem. You can omit the `--no-index` option when
+ running the command in a working tree controlled by Git and
+ at least one of the paths points outside the working tree,
+ or when running the command outside a working tree
+ controlled by Git.
'git diff' [--options] --cached [<commit>] [--] [<path>...]::
28 git-fast-import.html
View
@@ -1264,8 +1264,8 @@ <h3 id="_code_commit_code"><code>commit</code></h3>
('author' (SP &lt;name&gt;)? SP LT &lt;email&gt; GT SP &lt;when&gt; LF)?
'committer' (SP &lt;name&gt;)? SP LT &lt;email&gt; GT SP &lt;when&gt; LF
data
- ('from' SP &lt;committish&gt; LF)?
- ('merge' SP &lt;committish&gt; LF)?
+ ('from' SP &lt;commit-ish&gt; LF)?
+ ('merge' SP &lt;commit-ish&gt; LF)?
(filemodify | filedelete | filecopy | filerename | filedeleteall | notemodify)*
LF?</code></pre>
</div></div>
@@ -1334,8 +1334,8 @@ <h4 id="_code_from_code"><code>from</code></h4>
as the current commit on that branch is automatically assumed to
be the first ancestor of the new commit.</p></div>
<div class="paragraph"><p>As <code>LF</code> is not valid in a Git refname or SHA-1 expression, no
-quoting or escaping syntax is supported within <code>&lt;committish&gt;</code>.</p></div>
-<div class="paragraph"><p>Here <code>&lt;committish&gt;</code> is any of the following:</p></div>
+quoting or escaping syntax is supported within <code>&lt;commit-ish&gt;</code>.</p></div>
+<div class="paragraph"><p>Here <code>&lt;commit-ish&gt;</code> is any of the following:</p></div>
<div class="ulist"><ul>
<li>
<p>
@@ -1393,7 +1393,7 @@ <h4 id="_code_merge_code"><code>merge</code></h4>
additional ancestors (forming a 16-way merge). For this reason
it is suggested that frontends do not use more than 15 <code>merge</code>
commands per commit; 16, if starting a new, empty branch.</p></div>
-<div class="paragraph"><p>Here <code>&lt;committish&gt;</code> is any of the commit specification expressions
+<div class="paragraph"><p>Here <code>&lt;commit-ish&gt;</code> is any of the commit specification expressions
also accepted by <code>from</code> (see above).</p></div>
</div>
<div class="sect3">
@@ -1594,8 +1594,8 @@ <h4 id="_code_filedeleteall_code"><code>filedeleteall</code></h4>
<div class="sect3">
<h4 id="_code_notemodify_code"><code>notemodify</code></h4>
<div class="paragraph"><p>Included in a <code>commit</code> <code>&lt;notes_ref&gt;</code> command to add a new note
-annotating a <code>&lt;committish&gt;</code> or change this annotation contents.
-Internally it is similar to filemodify 100644 on <code>&lt;committish&gt;</code>
+annotating a <code>&lt;commit-ish&gt;</code> or change this annotation contents.
+Internally it is similar to filemodify 100644 on <code>&lt;commit-ish&gt;</code>
path (maybe split into subdirectories). It&#8217;s not advised to
use any other commands to write to the <code>&lt;notes_ref&gt;</code> tree except
<code>filedeleteall</code> to delete all existing notes in this tree.
@@ -1613,7 +1613,7 @@ <h4 id="_code_notemodify_code"><code>notemodify</code></h4>
</p>
<div class="literalblock">
<div class="content">
-<pre><code> 'N' SP &lt;dataref&gt; SP &lt;committish&gt; LF</code></pre>
+<pre><code> 'N' SP &lt;dataref&gt; SP &lt;commit-ish&gt; LF</code></pre>
</div></div>
<div class="paragraph"><p>Here <code>&lt;dataref&gt;</code> can be either a mark reference (<code>:&lt;idnum&gt;</code>)
set by a prior <code>blob</code> command, or a full 40-byte SHA-1 of an
@@ -1630,13 +1630,13 @@ <h4 id="_code_notemodify_code"><code>notemodify</code></h4>
</p>
<div class="literalblock">
<div class="content">
-<pre><code> 'N' SP 'inline' SP &lt;committish&gt; LF
+<pre><code> 'N' SP 'inline' SP &lt;commit-ish&gt; LF
data</code></pre>
</div></div>
<div class="paragraph"><p>See below for a detailed description of the <code>data</code> command.</p></div>
</dd>
</dl></div>
-<div class="paragraph"><p>In both formats <code>&lt;committish&gt;</code> is any of the commit specification
+<div class="paragraph"><p>In both formats <code>&lt;commit-ish&gt;</code> is any of the commit specification
expressions also accepted by <code>from</code> (see above).</p></div>
</div>
</div>
@@ -1666,7 +1666,7 @@ <h3 id="_code_tag_code"><code>tag</code></h3>
<div class="literalblock">
<div class="content">
<pre><code> 'tag' SP &lt;name&gt; LF
- 'from' SP &lt;committish&gt; LF
+ 'from' SP &lt;commit-ish&gt; LF
'tagger' (SP &lt;name&gt;)? SP LT &lt;email&gt; GT SP &lt;when&gt; LF
data</code></pre>
</div></div>
@@ -1704,10 +1704,10 @@ <h3 id="_code_reset_code"><code>reset</code></h3>
<div class="literalblock">
<div class="content">
<pre><code> 'reset' SP &lt;ref&gt; LF
- ('from' SP &lt;committish&gt; LF)?
+ ('from' SP &lt;commit-ish&gt; LF)?
LF?</code></pre>
</div></div>
-<div class="paragraph"><p>For a detailed description of <code>&lt;ref&gt;</code> and <code>&lt;committish&gt;</code> see above
+<div class="paragraph"><p>For a detailed description of <code>&lt;ref&gt;</code> and <code>&lt;commit-ish&gt;</code> see above
under <code>commit</code> and <code>from</code>.</p></div>
<div class="paragraph"><p>The <code>LF</code> after the command is optional (it used to be required).</p></div>
<div class="paragraph"><p>The <code>reset</code> command can also be used to create lightweight
@@ -2444,7 +2444,7 @@ <h2 id="_git">GIT</h2>
<div id="footnotes"><hr /></div>
<div id="footer">
<div id="footer-text">
-Last updated 2013-09-12 16:24:44 PDT
+Last updated 2013-09-17 14:33:14 PDT
</div>
</div>
</body>
26 git-fast-import.txt
View
@@ -380,8 +380,8 @@ change to the project.
('author' (SP <name>)? SP LT <email> GT SP <when> LF)?
'committer' (SP <name>)? SP LT <email> GT SP <when> LF
data
- ('from' SP <committish> LF)?
- ('merge' SP <committish> LF)?
+ ('from' SP <commit-ish> LF)?
+ ('merge' SP <commit-ish> LF)?
(filemodify | filedelete | filecopy | filerename | filedeleteall | notemodify)*
LF?
....
@@ -460,9 +460,9 @@ as the current commit on that branch is automatically assumed to
be the first ancestor of the new commit.
As `LF` is not valid in a Git refname or SHA-1 expression, no
-quoting or escaping syntax is supported within `<committish>`.
+quoting or escaping syntax is supported within `<commit-ish>`.
-Here `<committish>` is any of the following:
+Here `<commit-ish>` is any of the following:
* The name of an existing branch already in fast-import's internal branch
table. If fast-import doesn't know the name, it's treated as a SHA-1
@@ -509,7 +509,7 @@ additional ancestors (forming a 16-way merge). For this reason
it is suggested that frontends do not use more than 15 `merge`
commands per commit; 16, if starting a new, empty branch.
-Here `<committish>` is any of the commit specification expressions
+Here `<commit-ish>` is any of the commit specification expressions
also accepted by `from` (see above).
`filemodify`
@@ -677,8 +677,8 @@ paths for a commit are encouraged to do so.
`notemodify`
^^^^^^^^^^^^
Included in a `commit` `<notes_ref>` command to add a new note
-annotating a `<committish>` or change this annotation contents.
-Internally it is similar to filemodify 100644 on `<committish>`
+annotating a `<commit-ish>` or change this annotation contents.
+Internally it is similar to filemodify 100644 on `<commit-ish>`
path (maybe split into subdirectories). It's not advised to
use any other commands to write to the `<notes_ref>` tree except
`filedeleteall` to delete all existing notes in this tree.
@@ -691,7 +691,7 @@ External data format::
commit that is to be annotated.
+
....
- 'N' SP <dataref> SP <committish> LF
+ 'N' SP <dataref> SP <commit-ish> LF
....
+
Here `<dataref>` can be either a mark reference (`:<idnum>`)
@@ -704,13 +704,13 @@ Inline data format::
command.
+
....
- 'N' SP 'inline' SP <committish> LF
+ 'N' SP 'inline' SP <commit-ish> LF
data
....
+
See below for a detailed description of the `data` command.
-In both formats `<committish>` is any of the commit specification
+In both formats `<commit-ish>` is any of the commit specification
expressions also accepted by `from` (see above).
`mark`
@@ -741,7 +741,7 @@ lightweight (non-annotated) tags see the `reset` command below.
....
'tag' SP <name> LF
- 'from' SP <committish> LF
+ 'from' SP <commit-ish> LF
'tagger' (SP <name>)? SP LT <email> GT SP <when> LF
data
....
@@ -786,11 +786,11 @@ branch from an existing commit without creating a new commit.
....
'reset' SP <ref> LF
- ('from' SP <committish> LF)?
+ ('from' SP <commit-ish> LF)?
LF?
....
-For a detailed description of `<ref>` and `<committish>` see above
+For a detailed description of `<ref>` and `<commit-ish>` see above
under `commit` and `from`.
The `LF` after the command is optional (it used to be required).
4 git-merge-tree.html
View
@@ -754,7 +754,7 @@ <h2 id="_synopsis">SYNOPSIS</h2>
<div class="sect1">
<h2 id="_description">DESCRIPTION</h2>
<div class="sectionbody">
-<div class="paragraph"><p>Reads three treeish, and output trivial merge results and
+<div class="paragraph"><p>Reads three tree-ish, and output trivial merge results and
conflicting stages to the standard output. This is similar to
what three-way <em>git read-tree -m</em> does, but instead of storing the
results in the index, the command outputs the entries to the
@@ -775,7 +775,7 @@ <h2 id="_git">GIT</h2>
<div id="footnotes"><hr /></div>
<div id="footer">
<div id="footer-text">
-Last updated 2013-08-20 08:40:27 PDT
+Last updated 2013-09-17 14:33:14 PDT
</div>
</div>
</body>
2  git-merge-tree.txt
View
@@ -13,7 +13,7 @@ SYNOPSIS
DESCRIPTION
-----------
-Reads three treeish, and output trivial merge results and
+Reads three tree-ish, and output trivial merge results and
conflicting stages to the standard output. This is similar to
what three-way 'git read-tree -m' does, but instead of storing the
results in the index, the command outputs the entries to the
4 git-name-rev.html
View
@@ -747,7 +747,7 @@ <h2 id="_synopsis">SYNOPSIS</h2>
<div class="sectionbody">
<div class="verseblock">
<pre class="content"><em>git name-rev</em> [--tags] [--refs=&lt;pattern&gt;]
- ( --all | --stdin | &lt;committish&gt;&#8230; )</pre>
+ ( --all | --stdin | &lt;commit-ish&gt;&#8230; )</pre>
<div class="attribution">
</div></div>
</div>
@@ -861,7 +861,7 @@ <h2 id="_git">GIT</h2>
<div id="footnotes"><hr /></div>
<div id="footer">
<div id="footer-text">
-Last updated 2013-08-20 08:40:27 PDT
+Last updated 2013-09-17 14:33:14 PDT
</div>
</div>
</body>
2  git-name-rev.txt
View
@@ -10,7 +10,7 @@ SYNOPSIS
--------
[verse]
'git name-rev' [--tags] [--refs=<pattern>]
- ( --all | --stdin | <committish>... )
+ ( --all | --stdin | <commit-ish>... )
DESCRIPTION
-----------
4 git-push.html
View
@@ -905,7 +905,7 @@ <h2 id="_options_a_id_options_a">OPTIONS<a id="OPTIONS"></a></h2>
<p>
Push all the refs that would be pushed without this option,
and also push annotated tags in <code>refs/tags</code> that are missing
- from the remote but are pointing at committish that are
+ from the remote but are pointing at commit-ish that are
reachable from the refs being pushed.
</p>
</dd>
@@ -1722,7 +1722,7 @@ <h2 id="_git">GIT</h2>
<div id="footnotes"><hr /></div>
<div id="footer">
<div id="footer-text">
-Last updated 2013-09-09 15:34:20 PDT
+Last updated 2013-09-17 14:33:14 PDT
</div>
</div>
</body>
2  git-push.txt
View
@@ -121,7 +121,7 @@ already exists on the remote side.
--follow-tags::
Push all the refs that would be pushed without this option,
and also push annotated tags in `refs/tags` that are missing
- from the remote but are pointing at committish that are
+ from the remote but are pointing at commit-ish that are
reachable from the refs being pushed.
--receive-pack=<git-receive-pack>::
6 git-rebase.html
View
@@ -1172,7 +1172,7 @@ <h2 id="_options">OPTIONS</h2>
reverting a topic branch merge, as this option recreates the topic branch with
fresh commits so it can be remerged successfully without needing to "revert
the reversion" (see the
-<a href="howto/revert-a-faulty-merge.txt">revert-a-faulty-merge How-To</a> for details).</p></div>
+<a href="howto/revert-a-faulty-merge.html">revert-a-faulty-merge How-To</a> for details).</p></div>
</dd>
<dt class="hdlist1">
--ignore-whitespace
@@ -1318,7 +1318,7 @@ <h2 id="_options">OPTIONS</h2>
<div class="paragraph"><p>You may find this helpful after reverting a topic branch merge, as this option
recreates the topic branch with fresh commits so it can be remerged
successfully without needing to "revert the reversion" (see the
-<a href="howto/revert-a-faulty-merge.txt">revert-a-faulty-merge How-To</a> for details).</p></div>
+<a href="howto/revert-a-faulty-merge.html">revert-a-faulty-merge How-To</a> for details).</p></div>
</dd>
</dl></div>
</div>
@@ -1934,7 +1934,7 @@ <h2 id="_git">GIT</h2>
<div id="footnotes"><hr /></div>
<div id="footer">
<div id="footer-text">
-Last updated 2013-08-20 08:40:27 PDT
+Last updated 2013-09-17 14:33:14 PDT
</div>
</div>
</body>
4 git-rebase.txt
View
@@ -322,7 +322,7 @@ You may find this (or --no-ff with an interactive rebase) helpful after
reverting a topic branch merge, as this option recreates the topic branch with
fresh commits so it can be remerged successfully without needing to "revert
the reversion" (see the
-link:howto/revert-a-faulty-merge.txt[revert-a-faulty-merge How-To] for details).
+link:howto/revert-a-faulty-merge.html[revert-a-faulty-merge How-To] for details).
--ignore-whitespace::
--whitespace=<option>::
@@ -416,7 +416,7 @@ Without --interactive, this is a synonym for --force-rebase.
You may find this helpful after reverting a topic branch merge, as this option
recreates the topic branch with fresh commits so it can be remerged
successfully without needing to "revert the reversion" (see the
-link:howto/revert-a-faulty-merge.txt[revert-a-faulty-merge How-To] for details).
+link:howto/revert-a-faulty-merge.html[revert-a-faulty-merge How-To] for details).
include::merge-strategies.txt[]
12 git-rev-parse.html
View
@@ -1360,10 +1360,14 @@ <h2 id="_specifying_revisions">SPECIFYING REVISIONS</h2>
<dd>
<p>
A suffix <em>&#94;</em> followed by an object type name enclosed in
- brace pair means the object
- could be a tag, and dereference the tag recursively until an
- object of that type is found or the object cannot be
- dereferenced anymore (in which case, barf). <em>&lt;rev&gt;&#94;0</em>
+ brace pair means dereference the object at <em>&lt;rev&gt;</em> recursively until
+ an object of type <em>&lt;type&gt;</em> is found or the object cannot be
+ dereferenced anymore (in which case, barf).
+ For example, if <em>&lt;rev&gt;</em> is a commit-ish, <em>&lt;rev&gt;&#94;{commit}</em>
+ describes the corresponding commit object.
+ Similarly, if <em>&lt;rev&gt;</em> is a tree-ish, <em>&lt;rev&gt;&#94;{tree}</em>
+ describes the corresponding tree object.
+ <em>&lt;rev&gt;&#94;0</em>
is a short-hand for <em>&lt;rev&gt;&#94;{commit}</em>.
</p>
<div class="paragraph"><p><em>rev&#94;{object}</em> can be used to make sure <em>rev</em> names an
4 git-revert.html
View
@@ -819,7 +819,7 @@ <h2 id="_options">OPTIONS</h2>
brought in by the merge. As a result, later merges will only bring in tree
changes introduced by commits that are not ancestors of the previously
reverted merge. This may or may not be what you want.</p></div>
-<div class="paragraph"><p>See the <a href="howto/revert-a-faulty-merge.txt">revert-a-faulty-merge How-To</a> for
+<div class="paragraph"><p>See the <a href="howto/revert-a-faulty-merge.html">revert-a-faulty-merge How-To</a> for
more details.</p></div>
</dd>
<dt class="hdlist1">
@@ -966,7 +966,7 @@ <h2 id="_git">GIT</h2>
<div id="footnotes"><hr /></div>
<div id="footer">
<div id="footer-text">
-Last updated 2013-08-20 08:40:27 PDT
+Last updated 2013-09-17 14:33:14 PDT
</div>
</div>
</body>
2  git-revert.txt
View
@@ -59,7 +59,7 @@ brought in by the merge. As a result, later merges will only bring in tree
changes introduced by commits that are not ancestors of the previously
reverted merge. This may or may not be what you want.
+
-See the link:howto/revert-a-faulty-merge.txt[revert-a-faulty-merge How-To] for
+See the link:howto/revert-a-faulty-merge.html[revert-a-faulty-merge How-To] for
more details.
--no-edit::
4 gitcli.html
View
@@ -874,7 +874,7 @@ <h3 id="_magic_options">Magic Options</h3>
<div class="listingblock">
<div class="content">
<pre><code>$ git describe -h
-usage: git describe [options] &lt;committish&gt;*
+usage: git describe [options] &lt;commit-ish&gt;*
or: git describe [options] --dirty
--contains find the tag that comes after the commit
@@ -994,7 +994,7 @@ <h2 id="_git">GIT</h2>
<div id="footnotes"><hr /></div>
<div id="footer">
<div id="footer-text">
-Last updated 2013-08-20 08:40:27 PDT
+Last updated 2013-09-17 14:33:14 PDT
</div>
</div>
</body>
2  gitcli.txt
View
@@ -106,7 +106,7 @@ couple of magic command line options:
+
---------------------------------------------
$ git describe -h
-usage: git describe [options] <committish>*
+usage: git describe [options] <commit-ish>*
or: git describe [options] --dirty
--contains find the tag that comes after the commit
4 gitcvs-migration.html
View
@@ -890,7 +890,7 @@ <h2 id="_advanced_shared_repository_management">Advanced Shared Repository Manag
points. You can use these, for example, to send all commits to the shared
repository to a mailing list. See <a href="githooks.html">githooks(5)</a>.</p></div>
<div class="paragraph"><p>You can enforce finer grained permissions using update hooks. See
-<a href="howto/update-hook-example.txt">Controlling access to branches using
+<a href="howto/update-hook-example.html">Controlling access to branches using
update hooks</a>.</p></div>
</div>
</div>
@@ -943,7 +943,7 @@ <h2 id="_git">GIT</h2>
<div id="footnotes"><hr /></div>
<div id="footer">
<div id="footer-text">
-Last updated 2013-08-20 08:40:27 PDT
+Last updated 2013-09-17 14:33:14 PDT
</div>
</div>
</body>
2  gitcvs-migration.txt
View
@@ -157,7 +157,7 @@ points. You can use these, for example, to send all commits to the shared
repository to a mailing list. See linkgit:githooks[5].
You can enforce finer grained permissions using update hooks. See
-link:howto/update-hook-example.txt[Controlling access to branches using
+link:howto/update-hook-example.html[Controlling access to branches using
update hooks].
Providing CVS Access to a Git Repository
48 gitglossary.html
View
@@ -896,6 +896,23 @@ <h2 id="_description">DESCRIPTION</h2>
</p>
</dd>
<dt class="hdlist1">
+<a id="def_commit-ish"></a>commit-ish (also committish)
+</dt>
+<dd>
+<p>
+ A <a href="#def_commit_object">commit object</a> or an
+ <a href="#def_object">object</a> that can be recursively dereferenced to
+ a commit object.
+ The following are all commit-ishes:
+ a commit object,
+ a <a href="#def_tag_object">tag object</a> that points to a commit
+ object,
+ a tag object that points to a tag object that points to a
+ commit object,
+ etc.
+</p>
+</dd>
+<dt class="hdlist1">
<a id="def_core_git"></a>core Git
</dt>
<dd>
@@ -1481,11 +1498,19 @@ <h2 id="_description">DESCRIPTION</h2>
</dt>
<dd>
<p>
- A 40-byte hex representation of a <a href="#def_SHA1">SHA-1</a> or a name that
- denotes a particular <a href="#def_object">object</a>. They may be stored in
- a file under <code>$GIT_DIR/refs/</code> directory, or
- in the <code>$GIT_DIR/packed-refs</code> file.
+ A name that begins with <code>refs/</code> (e.g. <code>refs/heads/master</code>)
+ that points to an <a href="#def_object_name">object name</a> or another
+ ref (the latter is called a <a href="#def_symref">symbolic ref</a>).
+ For convenience, a ref can sometimes be abbreviated when used
+ as an argument to a Git command; see <a href="gitrevisions.html">gitrevisions(7)</a>
+ for details.
+ Refs are stored in the <a href="#def_repository">repository</a>.
</p>
+<div class="paragraph"><p>The ref namespace is hierarchical.
+Different subhierarchies are used for different purposes (e.g. the
+<code>refs/heads/</code> hierarchy is used to represent local branches).</p></div>
+<div class="paragraph"><p>There are a few special-purpose refs that do not begin with <code>refs/</code>.
+The most notable example is <code>HEAD</code>.</p></div>
</dd>
<dt class="hdlist1">
<a id="def_reflog"></a>reflog
@@ -1664,11 +1689,22 @@ <h2 id="_description">DESCRIPTION</h2>
</p>
</dd>
<dt class="hdlist1">
-<a id="def_tree-ish"></a>tree-ish
+<a id="def_tree-ish"></a>tree-ish (also treeish)
</dt>
<dd>
<p>
- A <a href="#def_ref">ref</a> pointing to either a <a href="#def_commit_object">commit object</a>, a <a href="#def_tree_object">tree object</a>, or a <a href="#def_tag_object">tag object</a> pointing to a tag or commit or tree object.
+ A <a href="#def_tree_object">tree object</a> or an <a href="#def_object">object</a>
+ that can be recursively dereferenced to a tree object.
+ Dereferencing a <a href="#def_commit_object">commit object</a> yields the
+ tree object corresponding to the <a href="#def_revision">revision</a>'s
+ top <a href="#def_directory">directory</a>.
+ The following are all tree-ishes:
+ a <a href="#def_commit-ish">commit-ish</a>,
+ a tree object,
+ a <a href="#def_tag_object">tag object</a> that points to a tree object,
+ a tag object that points to a tag object that points to a tree
+ object,
+ etc.
</p>
</dd>
<dt class="hdlist1">
12 gitrevisions.html
View
@@ -946,10 +946,14 @@ <h2 id="_specifying_revisions">SPECIFYING REVISIONS</h2>
<dd>
<p>
A suffix <em>&#94;</em> followed by an object type name enclosed in
- brace pair means the object
- could be a tag, and dereference the tag recursively until an
- object of that type is found or the object cannot be
- dereferenced anymore (in which case, barf). <em>&lt;rev&gt;&#94;0</em>
+ brace pair means dereference the object at <em>&lt;rev&gt;</em> recursively until
+ an object of type <em>&lt;type&gt;</em> is found or the object cannot be
+ dereferenced anymore (in which case, barf).
+ For example, if <em>&lt;rev&gt;</em> is a commit-ish, <em>&lt;rev&gt;&#94;{commit}</em>
+ describes the corresponding commit object.
+ Similarly, if <em>&lt;rev&gt;</em> is a tree-ish, <em>&lt;rev&gt;&#94;{tree}</em>
+ describes the corresponding tree object.
+ <em>&lt;rev&gt;&#94;0</em>
is a short-hand for <em>&lt;rev&gt;&#94;{commit}</em>.
</p>
<div class="paragraph"><p><em>rev&#94;{object}</em> can be used to make sure <em>rev</em> names an
47 glossary-content.txt
View
@@ -82,6 +82,18 @@ to point at the new commit.
to the top <<def_directory,directory>> of the stored
revision.
+[[def_commit-ish]]commit-ish (also committish)::
+ A <<def_commit_object,commit object>> or an
+ <<def_object,object>> that can be recursively dereferenced to
+ a commit object.
+ The following are all commit-ishes:
+ a commit object,
+ a <<def_tag_object,tag object>> that points to a commit
+ object,
+ a tag object that points to a tag object that points to a
+ commit object,
+ etc.
+
[[def_core_git]]core Git::
Fundamental data structures and utilities of Git. Exposes only limited
source code management tools.
@@ -427,10 +439,20 @@ should not be combined with other pathspec.
to the result.
[[def_ref]]ref::
- A 40-byte hex representation of a <<def_SHA1,SHA-1>> or a name that
- denotes a particular <<def_object,object>>. They may be stored in
- a file under `$GIT_DIR/refs/` directory, or
- in the `$GIT_DIR/packed-refs` file.
+ A name that begins with `refs/` (e.g. `refs/heads/master`)
+ that points to an <<def_object_name,object name>> or another
+ ref (the latter is called a <<def_symref,symbolic ref>>).
+ For convenience, a ref can sometimes be abbreviated when used
+ as an argument to a Git command; see linkgit:gitrevisions[7]
+ for details.
+ Refs are stored in the <<def_repository,repository>>.
++
+The ref namespace is hierarchical.
+Different subhierarchies are used for different purposes (e.g. the
+`refs/heads/` hierarchy is used to represent local branches).
++
+There are a few special-purpose refs that do not begin with `refs/`.
+The most notable example is `HEAD`.
[[def_reflog]]reflog::
A reflog shows the local "history" of a ref. In other words,
@@ -530,10 +552,19 @@ should not be combined with other pathspec.
with refs to the associated blob and/or tree objects. A
<<def_tree,tree>> is equivalent to a <<def_directory,directory>>.
-[[def_tree-ish]]tree-ish::
- A <<def_ref,ref>> pointing to either a <<def_commit_object,commit
- object>>, a <<def_tree_object,tree object>>, or a <<def_tag_object,tag
- object>> pointing to a tag or commit or tree object.
+[[def_tree-ish]]tree-ish (also treeish)::
+ A <<def_tree_object,tree object>> or an <<def_object,object>>
+ that can be recursively dereferenced to a tree object.
+ Dereferencing a <<def_commit_object,commit object>> yields the
+ tree object corresponding to the <<def_revision,revision>>'s
+ top <<def_directory,directory>>.
+ The following are all tree-ishes:
+ a <<def_commit-ish,commit-ish>>,
+ a tree object,
+ a <<def_tag_object,tag object>> that points to a tree object,
+ a tag object that points to a tag object that points to a tree
+ object,
+ etc.
[[def_unmerged_index]]unmerged index::
An <<def_index,index>> which contains unmerged
4 howto/revert-branch-rebase.html
View
@@ -867,7 +867,7 @@
Packing 0 objects
Unpacking 0 objects
-* committish: e3a693c... refs/heads/master from .
+* commit-ish: e3a693c... refs/heads/master from .
Trying to merge e3a693c... into 8c1f5f0... using 10d781b...
Committed merge 7fb9b7262a1d1e0a47bbfdcbbcf50ce0635d3f8f
cache.h | 8 ++++----
@@ -903,7 +903,7 @@
<div id="footnotes"><hr /></div>
<div id="footer">
<div id="footer-text">
-Last updated 2013-08-23 13:47:41 PDT
+Last updated 2013-09-17 14:33:23 PDT
</div>
</div>
</body>
2  howto/revert-branch-rebase.txt
View
@@ -154,7 +154,7 @@ $ git pull . master
Packing 0 objects
Unpacking 0 objects
-* committish: e3a693c... refs/heads/master from .
+* commit-ish: e3a693c... refs/heads/master from .
Trying to merge e3a693c... into 8c1f5f0... using 10d781b...
Committed merge 7fb9b7262a1d1e0a47bbfdcbbcf50ce0635d3f8f
cache.h | 8 ++++----
12 revisions.txt
View
@@ -111,10 +111,14 @@ some output processing may assume ref names in UTF-8.
'<rev>{caret}\{<type>\}', e.g. 'v0.99.8{caret}\{commit\}'::
A suffix '{caret}' followed by an object type name enclosed in
- brace pair means the object
- could be a tag, and dereference the tag recursively until an
- object of that type is found or the object cannot be
- dereferenced anymore (in which case, barf). '<rev>{caret}0'
+ brace pair means dereference the object at '<rev>' recursively until
+ an object of type '<type>' is found or the object cannot be
+ dereferenced anymore (in which case, barf).
+ For example, if '<rev>' is a commit-ish, '<rev>{caret}\{commit\}'
+ describes the corresponding commit object.
+ Similarly, if '<rev>' is a tree-ish, '<rev>{caret}\{tree\}'
+ describes the corresponding tree object.
+ '<rev>{caret}0'
is a short-hand for '<rev>{caret}\{commit\}'.
+
'rev{caret}\{object\}' can be used to make sure 'rev' names an
4 technical/http-protocol.txt
View
@@ -499,5 +499,5 @@ References
link:http://www.ietf.org/rfc/rfc1738.txt[RFC 1738: Uniform Resource Locators (URL)]
link:http://www.ietf.org/rfc/rfc2616.txt[RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1]
-link:technical/pack-protocol.txt
-link:technical/protocol-capabilities.txt
+link:technical/pack-protocol.html
+link:technical/protocol-capabilities.html
177 user-manual.html
View
@@ -1,5 +1,5 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
-<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title></title><link rel="stylesheet" type="text/css" href="docbook-xsl.css"><meta name="generator" content="DocBook XSL Stylesheets V1.76.1"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div lang="en" class="book"><div class="titlepage"><hr></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="part"><a href="#_git_user_8217_s_manual_for_version_1_5_3_or_newer">I. Git User’s Manual (for version 1.5.3 or newer)</a></span></dt><dd><dl><dt><span class="chapter"><a href="#repositories-and-branches">1. Repositories and Branches</a></span></dt><dd><dl><dt><span class="section"><a href="#how-to-get-a-git-repository">How to get a Git repository</a></span></dt><dt><span class="section"><a href="#how-to-check-out">How to check out a different version of a project</a></span></dt><dt><span class="section"><a href="#understanding-commits">Understanding History: Commits</a></span></dt><dd><dl><dt><span class="section"><a href="#understanding-reachability">Understanding history: commits, parents, and reachability</a></span></dt><dt><span class="section"><a href="#history-diagrams">Understanding history: History diagrams</a></span></dt><dt><span class="section"><a href="#what-is-a-branch">Understanding history: What is a branch?</a></span></dt></dl></dd><dt><span class="section"><a href="#manipulating-branches">Manipulating branches</a></span></dt><dt><span class="section"><a href="#detached-head">Examining an old version without creating a new branch</a></span></dt><dt><span class="section"><a href="#examining-remote-branches">Examining branches from a remote repository</a></span></dt><dt><span class="section"><a href="#how-git-stores-references">Naming branches, tags, and other references</a></span></dt><dt><span class="section"><a href="#Updating-a-repository-With-git-fetch">Updating a repository with git fetch</a></span></dt><dt><span class="section"><a href="#fetching-branches">Fetching branches from other repositories</a></span></dt></dl></dd><dt><span class="chapter"><a href="#exploring-git-history">2. Exploring Git history</a></span></dt><dd><dl><dt><span class="section"><a href="#using-bisect">How to use bisect to find a regression</a></span></dt><dt><span class="section"><a href="#naming-commits">Naming commits</a></span></dt><dt><span class="section"><a href="#creating-tags">Creating tags</a></span></dt><dt><span class="section"><a href="#browsing-revisions">Browsing revisions</a></span></dt><dt><span class="section"><a href="#generating-diffs">Generating diffs</a></span></dt><dt><span class="section"><a href="#viewing-old-file-versions">Viewing old file versions</a></span></dt><dt><span class="section"><a href="#history-examples">Examples</a></span></dt><dd><dl><dt><span class="section"><a href="#counting-commits-on-a-branch">Counting the number of commits on a branch</a></span></dt><dt><span class="section"><a href="#checking-for-equal-branches">Check whether two branches point at the same history</a></span></dt><dt><span class="section"><a href="#finding-tagged-descendants">Find first tagged version including a given fix</a></span></dt><dt><span class="section"><a href="#showing-commits-unique-to-a-branch">Showing commits unique to a given branch</a></span></dt><dt><span class="section"><a href="#making-a-release">Creating a changelog and tarball for a software release</a></span></dt><dt><span class="section"><a href="#Finding-commits-With-given-Content">Finding commits referencing a file with given content</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="#Developing-With-git">3. Developing with Git</a></span></dt><dd><dl><dt><span class="section"><a href="#telling-git-your-name">Telling Git your name</a></span></dt><dt><span class="section"><a href="#creating-a-new-repository">Creating a new repository</a></span></dt><dt><span class="section"><a href="#how-to-make-a-commit">How to make a commit</a></span></dt><dt><span class="section"><a href="#creating-good-commit-messages">Creating good commit messages</a></span></dt><dt><span class="section"><a href="#ignoring-files">Ignoring files</a></span></dt><dt><span class="section"><a href="#how-to-merge">How to merge</a></span></dt><dt><span class="section"><a href="#resolving-a-merge">Resolving a merge</a></span></dt><dd><dl><dt><span class="section"><a href="#conflict-resolution">Getting conflict-resolution help during a merge</a></span></dt></dl></dd><dt><span class="section"><a href="#undoing-a-merge">Undoing a merge</a></span></dt><dt><span class="section"><a href="#fast-forwards">Fast-forward merges</a></span></dt><dt><span class="section"><a href="#fixing-mistakes">Fixing mistakes</a></span></dt><dd><dl><dt><span class="section"><a href="#reverting-a-commit">Fixing a mistake with a new commit</a></span></dt><dt><span class="section"><a href="#fixing-a-mistake-by-rewriting-history">Fixing a mistake by rewriting history</a></span></dt><dt><span class="section"><a href="#checkout-of-path">Checking out an old version of a file</a></span></dt><dt><span class="section"><a href="#interrupted-work">Temporarily setting aside work in progress</a></span></dt></dl></dd><dt><span class="section"><a href="#ensuring-good-performance">Ensuring good performance</a></span></dt><dt><span class="section"><a href="#ensuring-reliability">Ensuring reliability</a></span></dt><dd><dl><dt><span class="section"><a href="#checking-for-corruption">Checking the repository for corruption</a></span></dt><dt><span class="section"><a href="#recovering-lost-changes">Recovering lost changes</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="#sharing-development">4. Sharing development with others</a></span></dt><dd><dl><dt><span class="section"><a href="#getting-updates-With-git-pull">Getting updates with git pull</a></span></dt><dt><span class="section"><a href="#submitting-patches">Submitting patches to a project</a></span></dt><dt><span class="section"><a href="#importing-patches">Importing patches to a project</a></span></dt><dt><span class="section"><a href="#public-repositories">Public Git repositories</a></span></dt><dd><dl><dt><span class="section"><a href="#setting-up-a-public-repository">Setting up a public repository</a></span></dt><dt><span class="section"><a href="#exporting-via-git">Exporting a Git repository via the Git protocol</a></span></dt><dt><span class="section"><a href="#exporting-via-http">Exporting a git repository via HTTP</a></span></dt><dt><span class="section"><a href="#pushing-changes-to-a-public-repository">Pushing changes to a public repository</a></span></dt><dt><span class="section"><a href="#forcing-push">What to do when a push fails</a></span></dt><dt><span class="section"><a href="#setting-up-a-shared-repository">Setting up a shared repository</a></span></dt><dt><span class="section"><a href="#setting-up-gitweb">Allowing web browsing of a repository</a></span></dt></dl></dd><dt><span class="section"><a href="#sharing-development-examples">Examples</a></span></dt><dd><dl><dt><span class="section"><a href="#maintaining-topic-branches">Maintaining topic branches for a Linux subsystem maintainer</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="#cleaning-up-history">5. Rewriting history and maintaining patch series</a></span></dt><dd><dl><dt><span class="section"><a href="#patch-series">Creating the perfect patch series</a></span></dt><dt><span class="section"><a href="#using-git-rebase">Keeping a patch series up to date using git rebase</a></span></dt><dt><span class="section"><a href="#rewriting-one-commit">Rewriting a single commit</a></span></dt><dt><span class="section"><a href="#reordering-patch-series">Reordering or selecting from a patch series</a></span></dt><dt><span class="section"><a href="#interactive-rebase">Using interactive rebases</a></span></dt><dt><span class="section"><a href="#patch-series-tools">Other tools</a></span></dt><dt><span class="section"><a href="#problems-With-rewriting-history">Problems with rewriting history</a></span></dt><dt><span class="section"><a href="#bisect-merges">Why bisecting merge commits can be harder than bisecting linear history</a></span></dt></dl></dd><dt><span class="chapter"><a href="#advanced-branch-management">6. Advanced branch management</a></span></dt><dd><dl><dt><span class="section"><a href="#fetching-individual-branches">Fetching individual branches</a></span></dt><dt><span class="section"><a href="#fetch-fast-forwards">git fetch and fast-forwards</a></span></dt><dt><span class="section"><a href="#forcing-fetch">Forcing git fetch to do non-fast-forward updates</a></span></dt><dt><span class="section"><a href="#remote-branch-configuration">Configuring remote-tracking branches</a></span></dt></dl></dd><dt><span class="chapter"><a href="#git-concepts">7. Git concepts</a></span></dt><dd><dl><dt><span class="section"><a href="#the-object-database">The Object Database</a></span></dt><dd><dl><dt><span class="section"><a href="#commit-object">Commit Object</a></span></dt><dt><span class="section"><a href="#tree-object">Tree Object</a></span></dt><dt><span class="section"><a href="#blob-object">Blob Object</a></span></dt><dt><span class="section"><a href="#trust">Trust</a></span></dt><dt><span class="section"><a href="#tag-object">Tag Object</a></span></dt><dt><span class="section"><a href="#pack-files">How Git stores objects efficiently: pack files</a></span></dt><dt><span class="section"><a href="#dangling-objects">Dangling objects</a></span></dt><dt><span class="section"><a href="#recovering-from-repository-corruption">Recovering from repository corruption</a></span></dt></dl></dd><dt><span class="section"><a href="#the-index">The index</a></span></dt></dl></dd><dt><span class="chapter"><a href="#submodules">8. Submodules</a></span></dt><dd><dl><dt><span class="section"><a href="#_pitfalls_with_submodules">Pitfalls with submodules</a></span></dt></dl></dd><dt><span class="chapter"><a href="#low-level-operations">9. Low-level Git operations</a></span></dt><dd><dl><dt><span class="section"><a href="#object-manipulation">Object access and manipulation</a></span></dt><dt><span class="section"><a href="#the-workflow">The Workflow</a></span></dt><dd><dl><dt><span class="section"><a href="#working-directory-to-index">working directory → index</a></span></dt><dt><span class="section"><a href="#index-to-object-database">index → object database</a></span></dt><dt><span class="section"><a href="#object-database-to-index">object database → index</a></span></dt><dt><span class="section"><a href="#index-to-working-directory">index → working directory</a></span></dt><dt><span class="section"><a href="#tying-it-all-together">Tying it all together</a></span></dt></dl></dd><dt><span class="section"><a href="#examining-the-data">Examining the data</a></span></dt><dt><span class="section"><a href="#merging-multiple-trees">Merging multiple trees</a></span></dt><dt><span class="section"><a href="#merging-multiple-trees-2">Merging multiple trees, continued</a></span></dt></dl></dd><dt><span class="chapter"><a href="#hacking-git">10. Hacking Git</a></span></dt><dd><dl><dt><span class="section"><a href="#object-details">Object storage format</a></span></dt><dt><span class="section"><a href="#birdview-on-the-source-code">A birds-eye view of Git’s source code</a></span></dt></dl></dd><dt><span class="chapter"><a href="#glossary">11. Git Glossary</a></span></dt><dt><span class="appendix"><a href="#git-quick-start">A. Git Quick Reference</a></span></dt><dd><dl><dt><span class="section"><a href="#quick-creating-a-new-repository">Creating a new repository</a></span></dt><dt><span class="section"><a href="#managing-branches">Managing branches</a></span></dt><dt><span class="section"><a href="#exploring-history">Exploring history</a></span></dt><dt><span class="section"><a href="#making-changes">Making changes</a></span></dt><dt><span class="section"><a href="#merging">Merging</a></span></dt><dt><span class="section"><a href="#sharing-your-changes">Sharing your changes</a></span></dt><dt><span class="section"><a href="#repository-maintenance">Repository maintenance</a></span></dt></dl></dd><dt><span class="appendix"><a href="#todo">B. Notes and todo list for this manual</a></span></dt></dl></dd></dl></div><div class="part" title="Part I. Git User’s Manual (for version 1.5.3 or newer)"><div class="titlepage"><div><div><h1 class="title"><a name="_git_user_8217_s_manual_for_version_1_5_3_or_newer"></a>Part I. Git User’s Manual (for version 1.5.3 or newer)</h1></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="chapter"><a href="#repositories-and-branches">1. Repositories and Branches</a></span></dt><dd><dl><dt><span class="section"><a href="#how-to-get-a-git-repository">How to get a Git repository</a></span></dt><dt><span class="section"><a href="#how-to-check-out">How to check out a different version of a project</a></span></dt><dt><span class="section"><a href="#understanding-commits">Understanding History: Commits</a></span></dt><dd><dl><dt><span class="section"><a href="#understanding-reachability">Understanding history: commits, parents, and reachability</a></span></dt><dt><span class="section"><a href="#history-diagrams">Understanding history: History diagrams</a></span></dt><dt><span class="section"><a href="#what-is-a-branch">Understanding history: What is a branch?</a></span></dt></dl></dd><dt><span class="section"><a href="#manipulating-branches">Manipulating branches</a></span></dt><dt><span class="section"><a href="#detached-head">Examining an old version without creating a new branch</a></span></dt><dt><span class="section"><a href="#examining-remote-branches">Examining branches from a remote repository</a></span></dt><dt><span class="section"><a href="#how-git-stores-references">Naming branches, tags, and other references</a></span></dt><dt><span class="section"><a href="#Updating-a-repository-With-git-fetch">Updating a repository with git fetch</a></span></dt><dt><span class="section"><a href="#fetching-branches">Fetching branches from other repositories</a></span></dt></dl></dd><dt><span class="chapter"><a href="#exploring-git-history">2. Exploring Git history</a></span></dt><dd><dl><dt><span class="section"><a href="#using-bisect">How to use bisect to find a regression</a></span></dt><dt><span class="section"><a href="#naming-commits">Naming commits</a></span></dt><dt><span class="section"><a href="#creating-tags">Creating tags</a></span></dt><dt><span class="section"><a href="#browsing-revisions">Browsing revisions</a></span></dt><dt><span class="section"><a href="#generating-diffs">Generating diffs</a></span></dt><dt><span class="section"><a href="#viewing-old-file-versions">Viewing old file versions</a></span></dt><dt><span class="section"><a href="#history-examples">Examples</a></span></dt><dd><dl><dt><span class="section"><a href="#counting-commits-on-a-branch">Counting the number of commits on a branch</a></span></dt><dt><span class="section"><a href="#checking-for-equal-branches">Check whether two branches point at the same history</a></span></dt><dt><span class="section"><a href="#finding-tagged-descendants">Find first tagged version including a given fix</a></span></dt><dt><span class="section"><a href="#showing-commits-unique-to-a-branch">Showing commits unique to a given branch</a></span></dt><dt><span class="section"><a href="#making-a-release">Creating a changelog and tarball for a software release</a></span></dt><dt><span class="section"><a href="#Finding-commits-With-given-Content">Finding commits referencing a file with given content</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="#Developing-With-git">3. Developing with Git</a></span></dt><dd><dl><dt><span class="section"><a href="#telling-git-your-name">Telling Git your name</a></span></dt><dt><span class="section"><a href="#creating-a-new-repository">Creating a new repository</a></span></dt><dt><span class="section"><a href="#how-to-make-a-commit">How to make a commit</a></span></dt><dt><span class="section"><a href="#creating-good-commit-messages">Creating good commit messages</a></span></dt><dt><span class="section"><a href="#ignoring-files">Ignoring files</a></span></dt><dt><span class="section"><a href="#how-to-merge">How to merge</a></span></dt><dt><span class="section"><a href="#resolving-a-merge">Resolving a merge</a></span></dt><dd><dl><dt><span class="section"><a href="#conflict-resolution">Getting conflict-resolution help during a merge</a></span></dt></dl></dd><dt><span class="section"><a href="#undoing-a-merge">Undoing a merge</a></span></dt><dt><span class="section"><a href="#fast-forwards">Fast-forward merges</a></span></dt><dt><span class="section"><a href="#fixing-mistakes">Fixing mistakes</a></span></dt><dd><dl><dt><span class="section"><a href="#reverting-a-commit">Fixing a mistake with a new commit</a></span></dt><dt><span class="section"><a href="#fixing-a-mistake-by-rewriting-history">Fixing a mistake by rewriting history</a></span></dt><dt><span class="section"><a href="#checkout-of-path">Checking out an old version of a file</a></span></dt><dt><span class="section"><a href="#interrupted-work">Temporarily setting aside work in progress</a></span></dt></dl></dd><dt><span class="section"><a href="#ensuring-good-performance">Ensuring good performance</a></span></dt><dt><span class="section"><a href="#ensuring-reliability">Ensuring reliability</a></span></dt><dd><dl><dt><span class="section"><a href="#checking-for-corruption">Checking the repository for corruption</a></span></dt><dt><span class="section"><a href="#recovering-lost-changes">Recovering lost changes</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="#sharing-development">4. Sharing development with others</a></span></dt><dd><dl><dt><span class="section"><a href="#getting-updates-With-git-pull">Getting updates with git pull</a></span></dt><dt><span class="section"><a href="#submitting-patches">Submitting patches to a project</a></span></dt><dt><span class="section"><a href="#importing-patches">Importing patches to a project</a></span></dt><dt><span class="section"><a href="#public-repositories">Public Git repositories</a></span></dt><dd><dl><dt><span class="section"><a href="#setting-up-a-public-repository">Setting up a public repository</a></span></dt><dt><span class="section"><a href="#exporting-via-git">Exporting a Git repository via the Git protocol</a></span></dt><dt><span class="section"><a href="#exporting-via-http">Exporting a git repository via HTTP</a></span></dt><dt><span class="section"><a href="#pushing-changes-to-a-public-repository">Pushing changes to a public repository</a></span></dt><dt><span class="section"><a href="#forcing-push">What to do when a push fails</a></span></dt><dt><span class="section"><a href="#setting-up-a-shared-repository">Setting up a shared repository</a></span></dt><dt><span class="section"><a href="#setting-up-gitweb">Allowing web browsing of a repository</a></span></dt></dl></dd><dt><span class="section"><a href="#sharing-development-examples">Examples</a></span></dt><dd><dl><dt><span class="section"><a href="#maintaining-topic-branches">Maintaining topic branches for a Linux subsystem maintainer</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="#cleaning-up-history">5. Rewriting history and maintaining patch series</a></span></dt><dd><dl><dt><span class="section"><a href="#patch-series">Creating the perfect patch series</a></span></dt><dt><span class="section"><a href="#using-git-rebase">Keeping a patch series up to date using git rebase</a></span></dt><dt><span class="section"><a href="#rewriting-one-commit">Rewriting a single commit</a></span></dt><dt><span class="section"><a href="#reordering-patch-series">Reordering or selecting from a patch series</a></span></dt><dt><span class="section"><a href="#interactive-rebase">Using interactive rebases</a></span></dt><dt><span class="section"><a href="#patch-series-tools">Other tools</a></span></dt><dt><span class="section"><a href="#problems-With-rewriting-history">Problems with rewriting history</a></span></dt><dt><span class="section"><a href="#bisect-merges">Why bisecting merge commits can be harder than bisecting linear history</a></span></dt></dl></dd><dt><span class="chapter"><a href="#advanced-branch-management">6. Advanced branch management</a></span></dt><dd><dl><dt><span class="section"><a href="#fetching-individual-branches">Fetching individual branches</a></span></dt><dt><span class="section"><a href="#fetch-fast-forwards">git fetch and fast-forwards</a></span></dt><dt><span class="section"><a href="#forcing-fetch">Forcing git fetch to do non-fast-forward updates</a></span></dt><dt><span class="section"><a href="#remote-branch-configuration">Configuring remote-tracking branches</a></span></dt></dl></dd><dt><span class="chapter"><a href="#git-concepts">7. Git concepts</a></span></dt><dd><dl><dt><span class="section"><a href="#the-object-database">The Object Database</a></span></dt><dd><dl><dt><span class="section"><a href="#commit-object">Commit Object</a></span></dt><dt><span class="section"><a href="#tree-object">Tree Object</a></span></dt><dt><span class="section"><a href="#blob-object">Blob Object</a></span></dt><dt><span class="section"><a href="#trust">Trust</a></span></dt><dt><span class="section"><a href="#tag-object">Tag Object</a></span></dt><dt><span class="section"><a href="#pack-files">How Git stores objects efficiently: pack files</a></span></dt><dt><span class="section"><a href="#dangling-objects">Dangling objects</a></span></dt><dt><span class="section"><a href="#recovering-from-repository-corruption">Recovering from repository corruption</a></span></dt></dl></dd><dt><span class="section"><a href="#the-index">The index</a></span></dt></dl></dd><dt><span class="chapter"><a href="#submodules">8. Submodules</a></span></dt><dd><dl><dt><span class="section"><a href="#_pitfalls_with_submodules">Pitfalls with submodules</a></span></dt></dl></dd><dt><span class="chapter"><a href="#low-level-operations">9. Low-level Git operations</a></span></dt><dd><dl><dt><span class="section"><a href="#object-manipulation">Object access and manipulation</a></span></dt><dt><span class="section"><a href="#the-workflow">The Workflow</a></span></dt><dd><dl><dt><span class="section"><a href="#working-directory-to-index">working directory → index</a></span></dt><dt><span class="section"><a href="#index-to-object-database">index → object database</a></span></dt><dt><span class="section"><a href="#object-database-to-index">object database → index</a></span></dt><dt><span class="section"><a href="#index-to-working-directory">index → working directory</a></span></dt><dt><span class="section"><a href="#tying-it-all-together">Tying it all together</a></span></dt></dl></dd><dt><span class="section"><a href="#examining-the-data">Examining the data</a></span></dt><dt><span class="section"><a href="#merging-multiple-trees">Merging multiple trees</a></span></dt><dt><span class="section"><a href="#merging-multiple-trees-2">Merging multiple trees, continued</a></span></dt></dl></dd><dt><span class="chapter"><a href="#hacking-git">10. Hacking Git</a></span></dt><dd><dl><dt><span class="section"><a href="#object-details">Object storage format</a></span></dt><dt><span class="section"><a href="#birdview-on-the-source-code">A birds-eye view of Git’s source code</a></span></dt></dl></dd><dt><span class="chapter"><a href="#glossary">11. Git Glossary</a></span></dt><dt><span class="appendix"><a href="#git-quick-start">A. Git Quick Reference</a></span></dt><dd><dl><dt><span class="section"><a href="#quick-creating-a-new-repository">Creating a new repository</a></span></dt><dt><span class="section"><a href="#managing-branches">Managing branches</a></span></dt><dt><span class="section"><a href="#exploring-history">Exploring history</a></span></dt><dt><span class="section"><a href="#making-changes">Making changes</a></span></dt><dt><span class="section"><a href="#merging">Merging</a></span></dt><dt><span class="section"><a href="#sharing-your-changes">Sharing your changes</a></span></dt><dt><span class="section"><a href="#repository-maintenance">Repository maintenance</a></span></dt></dl></dd><dt><span class="appendix"><a href="#todo">B. Notes and todo list for this manual</a></span></dt></dl></div><p>Git is a fast distributed revision control system.</p><p>This manual is designed to be readable by someone with basic UNIX
+<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><title></title><link rel="stylesheet" type="text/css" href="docbook-xsl.css"><meta name="generator" content="DocBook XSL Stylesheets V1.76.1"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div lang="en" class="book"><div class="titlepage"><hr></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="part"><a href="#_git_user_manual">I. Git User Manual</a></span></dt><dd><dl><dt><span class="chapter"><a href="#repositories-and-branches">1. Repositories and Branches</a></span></dt><dd><dl><dt><span class="section"><a href="#how-to-get-a-git-repository">How to get a Git repository</a></span></dt><dt><span class="section"><a href="#how-to-check-out">How to check out a different version of a project</a></span></dt><dt><span class="section"><a href="#understanding-commits">Understanding History: Commits</a></span></dt><dd><dl><dt><span class="section"><a href="#understanding-reachability">Understanding history: commits, parents, and reachability</a></span></dt><dt><span class="section"><a href="#history-diagrams">Understanding history: History diagrams</a></span></dt><dt><span class="section"><a href="#what-is-a-branch">Understanding history: What is a branch?</a></span></dt></dl></dd><dt><span class="section"><a href="#manipulating-branches">Manipulating branches</a></span></dt><dt><span class="section"><a href="#detached-head">Examining an old version without creating a new branch</a></span></dt><dt><span class="section"><a href="#examining-remote-branches">Examining branches from a remote repository</a></span></dt><dt><span class="section"><a href="#how-git-stores-references">Naming branches, tags, and other references</a></span></dt><dt><span class="section"><a href="#Updating-a-repository-With-git-fetch">Updating a repository with git fetch</a></span></dt><dt><span class="section"><a href="#fetching-branches">Fetching branches from other repositories</a></span></dt></dl></dd><dt><span class="chapter"><a href="#exploring-git-history">2. Exploring Git history</a></span></dt><dd><dl><dt><span class="section"><a href="#using-bisect">How to use bisect to find a regression</a></span></dt><dt><span class="section"><a href="#naming-commits">Naming commits</a></span></dt><dt><span class="section"><a href="#creating-tags">Creating tags</a></span></dt><dt><span class="section"><a href="#browsing-revisions">Browsing revisions</a></span></dt><dt><span class="section"><a href="#generating-diffs">Generating diffs</a></span></dt><dt><span class="section"><a href="#viewing-old-file-versions">Viewing old file versions</a></span></dt><dt><span class="section"><a href="#history-examples">Examples</a></span></dt><dd><dl><dt><span class="section"><a href="#counting-commits-on-a-branch">Counting the number of commits on a branch</a></span></dt><dt><span class="section"><a href="#checking-for-equal-branches">Check whether two branches point at the same history</a></span></dt><dt><span class="section"><a href="#finding-tagged-descendants">Find first tagged version including a given fix</a></span></dt><dt><span class="section"><a href="#showing-commits-unique-to-a-branch">Showing commits unique to a given branch</a></span></dt><dt><span class="section"><a href="#making-a-release">Creating a changelog and tarball for a software release</a></span></dt><dt><span class="section"><a href="#Finding-commits-With-given-Content">Finding commits referencing a file with given content</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="#Developing-With-git">3. Developing with Git</a></span></dt><dd><dl><dt><span class="section"><a href="#telling-git-your-name">Telling Git your name</a></span></dt><dt><span class="section"><a href="#creating-a-new-repository">Creating a new repository</a></span></dt><dt><span class="section"><a href="#how-to-make-a-commit">How to make a commit</a></span></dt><dt><span class="section"><a href="#creating-good-commit-messages">Creating good commit messages</a></span></dt><dt><span class="section"><a href="#ignoring-files">Ignoring files</a></span></dt><dt><span class="section"><a href="#how-to-merge">How to merge</a></span></dt><dt><span class="section"><a href="#resolving-a-merge">Resolving a merge</a></span></dt><dd><dl><dt><span class="section"><a href="#conflict-resolution">Getting conflict-resolution help during a merge</a></span></dt></dl></dd><dt><span class="section"><a href="#undoing-a-merge">Undoing a merge</a></span></dt><dt><span class="section"><a href="#fast-forwards">Fast-forward merges</a></span></dt><dt><span class="section"><a href="#fixing-mistakes">Fixing mistakes</a></span></dt><dd><dl><dt><span class="section"><a href="#reverting-a-commit">Fixing a mistake with a new commit</a></span></dt><dt><span class="section"><a href="#fixing-a-mistake-by-rewriting-history">Fixing a mistake by rewriting history</a></span></dt><dt><span class="section"><a href="#checkout-of-path">Checking out an old version of a file</a></span></dt><dt><span class="section"><a href="#interrupted-work">Temporarily setting aside work in progress</a></span></dt></dl></dd><dt><span class="section"><a href="#ensuring-good-performance">Ensuring good performance</a></span></dt><dt><span class="section"><a href="#ensuring-reliability">Ensuring reliability</a></span></dt><dd><dl><dt><span class="section"><a href="#checking-for-corruption">Checking the repository for corruption</a></span></dt><dt><span class="section"><a href="#recovering-lost-changes">Recovering lost changes</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="#sharing-development">4. Sharing development with others</a></span></dt><dd><dl><dt><span class="section"><a href="#getting-updates-With-git-pull">Getting updates with git pull</a></span></dt><dt><span class="section"><a href="#submitting-patches">Submitting patches to a project</a></span></dt><dt><span class="section"><a href="#importing-patches">Importing patches to a project</a></span></dt><dt><span class="section"><a href="#public-repositories">Public Git repositories</a></span></dt><dd><dl><dt><span class="section"><a href="#setting-up-a-public-repository">Setting up a public repository</a></span></dt><dt><span class="section"><a href="#exporting-via-git">Exporting a Git repository via the Git protocol</a></span></dt><dt><span class="section"><a href="#exporting-via-http">Exporting a git repository via HTTP</a></span></dt><dt><span class="section"><a href="#pushing-changes-to-a-public-repository">Pushing changes to a public repository</a></span></dt><dt><span class="section"><a href="#forcing-push">What to do when a push fails</a></span></dt><dt><span class="section"><a href="#setting-up-a-shared-repository">Setting up a shared repository</a></span></dt><dt><span class="section"><a href="#setting-up-gitweb">Allowing web browsing of a repository</a></span></dt></dl></dd><dt><span class="section"><a href="#sharing-development-examples">Examples</a></span></dt><dd><dl><dt><span class="section"><a href="#maintaining-topic-branches">Maintaining topic branches for a Linux subsystem maintainer</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="#cleaning-up-history">5. Rewriting history and maintaining patch series</a></span></dt><dd><dl><dt><span class="section"><a href="#patch-series">Creating the perfect patch series</a></span></dt><dt><span class="section"><a href="#using-git-rebase">Keeping a patch series up to date using git rebase</a></span></dt><dt><span class="section"><a href="#rewriting-one-commit">Rewriting a single commit</a></span></dt><dt><span class="section"><a href="#reordering-patch-series">Reordering or selecting from a patch series</a></span></dt><dt><span class="section"><a href="#interactive-rebase">Using interactive rebases</a></span></dt><dt><span class="section"><a href="#patch-series-tools">Other tools</a></span></dt><dt><span class="section"><a href="#problems-With-rewriting-history">Problems with rewriting history</a></span></dt><dt><span class="section"><a href="#bisect-merges">Why bisecting merge commits can be harder than bisecting linear history</a></span></dt></dl></dd><dt><span class="chapter"><a href="#advanced-branch-management">6. Advanced branch management</a></span></dt><dd><dl><dt><span class="section"><a href="#fetching-individual-branches">Fetching individual branches</a></span></dt><dt><span class="section"><a href="#fetch-fast-forwards">git fetch and fast-forwards</a></span></dt><dt><span class="section"><a href="#forcing-fetch">Forcing git fetch to do non-fast-forward updates</a></span></dt><dt><span class="section"><a href="#remote-branch-configuration">Configuring remote-tracking branches</a></span></dt></dl></dd><dt><span class="chapter"><a href="#git-concepts">7. Git concepts</a></span></dt><dd><dl><dt><span class="section"><a href="#the-object-database">The Object Database</a></span></dt><dd><dl><dt><span class="section"><a href="#commit-object">Commit Object</a></span></dt><dt><span class="section"><a href="#tree-object">Tree Object</a></span></dt><dt><span class="section"><a href="#blob-object">Blob Object</a></span></dt><dt><span class="section"><a href="#trust">Trust</a></span></dt><dt><span class="section"><a href="#tag-object">Tag Object</a></span></dt><dt><span class="section"><a href="#pack-files">How Git stores objects efficiently: pack files</a></span></dt><dt><span class="section"><a href="#dangling-objects">Dangling objects</a></span></dt><dt><span class="section"><a href="#recovering-from-repository-corruption">Recovering from repository corruption</a></span></dt></dl></dd><dt><span class="section"><a href="#the-index">The index</a></span></dt></dl></dd><dt><span class="chapter"><a href="#submodules">8. Submodules</a></span></dt><dd><dl><dt><span class="section"><a href="#_pitfalls_with_submodules">Pitfalls with submodules</a></span></dt></dl></dd><dt><span class="chapter"><a href="#low-level-operations">9. Low-level Git operations</a></span></dt><dd><dl><dt><span class="section"><a href="#object-manipulation">Object access and manipulation</a></span></dt><dt><span class="section"><a href="#the-workflow">The Workflow</a></span></dt><dd><dl><dt><span class="section"><a href="#working-directory-to-index">working directory → index</a></span></dt><dt><span class="section"><a href="#index-to-object-database">index → object database</a></span></dt><dt><span class="section"><a href="#object-database-to-index">object database → index</a></span></dt><dt><span class="section"><a href="#index-to-working-directory">index → working directory</a></span></dt><dt><span class="section"><a href="#tying-it-all-together">Tying it all together</a></span></dt></dl></dd><dt><span class="section"><a href="#examining-the-data">Examining the data</a></span></dt><dt><span class="section"><a href="#merging-multiple-trees">Merging multiple trees</a></span></dt><dt><span class="section"><a href="#merging-multiple-trees-2">Merging multiple trees, continued</a></span></dt></dl></dd><dt><span class="chapter"><a href="#hacking-git">10. Hacking Git</a></span></dt><dd><dl><dt><span class="section"><a href="#object-details">Object storage format</a></span></dt><dt><span class="section"><a href="#birdview-on-the-source-code">A birds-eye view of Git’s source code</a></span></dt></dl></dd><dt><span class="chapter"><a href="#glossary">11. Git Glossary</a></span></dt><dt><span class="appendix"><a href="#git-quick-start">A. Git Quick Reference</a></span></dt><dd><dl><dt><span class="section"><a href="#quick-creating-a-new-repository">Creating a new repository</a></span></dt><dt><span class="section"><a href="#managing-branches">Managing branches</a></span></dt><dt><span class="section"><a href="#exploring-history">Exploring history</a></span></dt><dt><span class="section"><a href="#making-changes">Making changes</a></span></dt><dt><span class="section"><a href="#merging">Merging</a></span></dt><dt><span class="section"><a href="#sharing-your-changes">Sharing your changes</a></span></dt><dt><span class="section"><a href="#repository-maintenance">Repository maintenance</a></span></dt></dl></dd><dt><span class="appendix"><a href="#todo">B. Notes and todo list for this manual</a></span></dt></dl></dd></dl></div><div class="part" title="Part I. Git User Manual"><div class="titlepage"><div><div><h1 class="title"><a name="_git_user_manual"></a>Part I. Git User Manual</h1></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="chapter"><a href="#repositories-and-branches">1. Repositories and Branches</a></span></dt><dd><dl><dt><span class="section"><a href="#how-to-get-a-git-repository">How to get a Git repository</a></span></dt><dt><span class="section"><a href="#how-to-check-out">How to check out a different version of a project</a></span></dt><dt><span class="section"><a href="#understanding-commits">Understanding History: Commits</a></span></dt><dd><dl><dt><span class="section"><a href="#understanding-reachability">Understanding history: commits, parents, and reachability</a></span></dt><dt><span class="section"><a href="#history-diagrams">Understanding history: History diagrams</a></span></dt><dt><span class="section"><a href="#what-is-a-branch">Understanding history: What is a branch?</a></span></dt></dl></dd><dt><span class="section"><a href="#manipulating-branches">Manipulating branches</a></span></dt><dt><span class="section"><a href="#detached-head">Examining an old version without creating a new branch</a></span></dt><dt><span class="section"><a href="#examining-remote-branches">Examining branches from a remote repository</a></span></dt><dt><span class="section"><a href="#how-git-stores-references">Naming branches, tags, and other references</a></span></dt><dt><span class="section"><a href="#Updating-a-repository-With-git-fetch">Updating a repository with git fetch</a></span></dt><dt><span class="section"><a href="#fetching-branches">Fetching branches from other repositories</a></span></dt></dl></dd><dt><span class="chapter"><a href="#exploring-git-history">2. Exploring Git history</a></span></dt><dd><dl><dt><span class="section"><a href="#using-bisect">How to use bisect to find a regression</a></span></dt><dt><span class="section"><a href="#naming-commits">Naming commits</a></span></dt><dt><span class="section"><a href="#creating-tags">Creating tags</a></span></dt><dt><span class="section"><a href="#browsing-revisions">Browsing revisions</a></span></dt><dt><span class="section"><a href="#generating-diffs">Generating diffs</a></span></dt><dt><span class="section"><a href="#viewing-old-file-versions">Viewing old file versions</a></span></dt><dt><span class="section"><a href="#history-examples">Examples</a></span></dt><dd><dl><dt><span class="section"><a href="#counting-commits-on-a-branch">Counting the number of commits on a branch</a></span></dt><dt><span class="section"><a href="#checking-for-equal-branches">Check whether two branches point at the same history</a></span></dt><dt><span class="section"><a href="#finding-tagged-descendants">Find first tagged version including a given fix</a></span></dt><dt><span class="section"><a href="#showing-commits-unique-to-a-branch">Showing commits unique to a given branch</a></span></dt><dt><span class="section"><a href="#making-a-release">Creating a changelog and tarball for a software release</a></span></dt><dt><span class="section"><a href="#Finding-commits-With-given-Content">Finding commits referencing a file with given content</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="#Developing-With-git">3. Developing with Git</a></span></dt><dd><dl><dt><span class="section"><a href="#telling-git-your-name">Telling Git your name</a></span></dt><dt><span class="section"><a href="#creating-a-new-repository">Creating a new repository</a></span></dt><dt><span class="section"><a href="#how-to-make-a-commit">How to make a commit</a></span></dt><dt><span class="section"><a href="#creating-good-commit-messages">Creating good commit messages</a></span></dt><dt><span class="section"><a href="#ignoring-files">Ignoring files</a></span></dt><dt><span class="section"><a href="#how-to-merge">How to merge</a></span></dt><dt><span class="section"><a href="#resolving-a-merge">Resolving a merge</a></span></dt><dd><dl><dt><span class="section"><a href="#conflict-resolution">Getting conflict-resolution help during a merge</a></span></dt></dl></dd><dt><span class="section"><a href="#undoing-a-merge">Undoing a merge</a></span></dt><dt><span class="section"><a href="#fast-forwards">Fast-forward merges</a></span></dt><dt><span class="section"><a href="#fixing-mistakes">Fixing mistakes</a></span></dt><dd><dl><dt><span class="section"><a href="#reverting-a-commit">Fixing a mistake with a new commit</a></span></dt><dt><span class="section"><a href="#fixing-a-mistake-by-rewriting-history">Fixing a mistake by rewriting history</a></span></dt><dt><span class="section"><a href="#checkout-of-path">Checking out an old version of a file</a></span></dt><dt><span class="section"><a href="#interrupted-work">Temporarily setting aside work in progress</a></span></dt></dl></dd><dt><span class="section"><a href="#ensuring-good-performance">Ensuring good performance</a></span></dt><dt><span class="section"><a href="#ensuring-reliability">Ensuring reliability</a></span></dt><dd><dl><dt><span class="section"><a href="#checking-for-corruption">Checking the repository for corruption</a></span></dt><dt><span class="section"><a href="#recovering-lost-changes">Recovering lost changes</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="#sharing-development">4. Sharing development with others</a></span></dt><dd><dl><dt><span class="section"><a href="#getting-updates-With-git-pull">Getting updates with git pull</a></span></dt><dt><span class="section"><a href="#submitting-patches">Submitting patches to a project</a></span></dt><dt><span class="section"><a href="#importing-patches">Importing patches to a project</a></span></dt><dt><span class="section"><a href="#public-repositories">Public Git repositories</a></span></dt><dd><dl><dt><span class="section"><a href="#setting-up-a-public-repository">Setting up a public repository</a></span></dt><dt><span class="section"><a href="#exporting-via-git">Exporting a Git repository via the Git protocol</a></span></dt><dt><span class="section"><a href="#exporting-via-http">Exporting a git repository via HTTP</a></span></dt><dt><span class="section"><a href="#pushing-changes-to-a-public-repository">Pushing changes to a public repository</a></span></dt><dt><span class="section"><a href="#forcing-push">What to do when a push fails</a></span></dt><dt><span class="section"><a href="#setting-up-a-shared-repository">Setting up a shared repository</a></span></dt><dt><span class="section"><a href="#setting-up-gitweb">Allowing web browsing of a repository</a></span></dt></dl></dd><dt><span class="section"><a href="#sharing-development-examples">Examples</a></span></dt><dd><dl><dt><span class="section"><a href="#maintaining-topic-branches">Maintaining topic branches for a Linux subsystem maintainer</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="#cleaning-up-history">5. Rewriting history and maintaining patch series</a></span></dt><dd><dl><dt><span class="section"><a href="#patch-series">Creating the perfect patch series</a></span></dt><dt><span class="section"><a href="#using-git-rebase">Keeping a patch series up to date using git rebase</a></span></dt><dt><span class="section"><a href="#rewriting-one-commit">Rewriting a single commit</a></span></dt><dt><span class="section"><a href="#reordering-patch-series">Reordering or selecting from a patch series</a></span></dt><dt><span class="section"><a href="#interactive-rebase">Using interactive rebases</a></span></dt><dt><span class="section"><a href="#patch-series-tools">Other tools</a></span></dt><dt><span class="section"><a href="#problems-With-rewriting-history">Problems with rewriting history</a></span></dt><dt><span class="section"><a href="#bisect-merges">Why bisecting merge commits can be harder than bisecting linear history</a></span></dt></dl></dd><dt><span class="chapter"><a href="#advanced-branch-management">6. Advanced branch management</a></span></dt><dd><dl><dt><span class="section"><a href="#fetching-individual-branches">Fetching individual branches</a></span></dt><dt><span class="section"><a href="#fetch-fast-forwards">git fetch and fast-forwards</a></span></dt><dt><span class="section"><a href="#forcing-fetch">Forcing git fetch to do non-fast-forward updates</a></span></dt><dt><span class="section"><a href="#remote-branch-configuration">Configuring remote-tracking branches</a></span></dt></dl></dd><dt><span class="chapter"><a href="#git-concepts">7. Git concepts</a></span></dt><dd><dl><dt><span class="section"><a href="#the-object-database">The Object Database</a></span></dt><dd><dl><dt><span class="section"><a href="#commit-object">Commit Object</a></span></dt><dt><span class="section"><a href="#tree-object">Tree Object</a></span></dt><dt><span class="section"><a href="#blob-object">Blob Object</a></span></dt><dt><span class="section"><a href="#trust">Trust</a></span></dt><dt><span class="section"><a href="#tag-object">Tag Object</a></span></dt><dt><span class="section"><a href="#pack-files">How Git stores objects efficiently: pack files</a></span></dt><dt><span class="section"><a href="#dangling-objects">Dangling objects</a></span></dt><dt><span class="section"><a href="#recovering-from-repository-corruption">Recovering from repository corruption</a></span></dt></dl></dd><dt><span class="section"><a href="#the-index">The index</a></span></dt></dl></dd><dt><span class="chapter"><a href="#submodules">8. Submodules</a></span></dt><dd><dl><dt><span class="section"><a href="#_pitfalls_with_submodules">Pitfalls with submodules</a></span></dt></dl></dd><dt><span class="chapter"><a href="#low-level-operations">9. Low-level Git operations</a></span></dt><dd><dl><dt><span class="section"><a href="#object-manipulation">Object access and manipulation</a></span></dt><dt><span class="section"><a href="#the-workflow">The Workflow</a></span></dt><dd><dl><dt><span class="section"><a href="#working-directory-to-index">working directory → index</a></span></dt><dt><span class="section"><a href="#index-to-object-database">index → object database</a></span></dt><dt><span class="section"><a href="#object-database-to-index">object database → index</a></span></dt><dt><span class="section"><a href="#index-to-working-directory">index → working directory</a></span></dt><dt><span class="section"><a href="#tying-it-all-together">Tying it all together</a></span></dt></dl></dd><dt><span class="section"><a href="#examining-the-data">Examining the data</a></span></dt><dt><span class="section"><a href="#merging-multiple-trees">Merging multiple trees</a></span></dt><dt><span class="section"><a href="#merging-multiple-trees-2">Merging multiple trees, continued</a></span></dt></dl></dd><dt><span class="chapter"><a href="#hacking-git">10. Hacking Git</a></span></dt><dd><dl><dt><span class="section"><a href="#object-details">Object storage format</a></span></dt><dt><span class="section"><a href="#birdview-on-the-source-code">A birds-eye view of Git’s source code</a></span></dt></dl></dd><dt><span class="chapter"><a href="#glossary">11. Git Glossary</a></span></dt><dt><span class="appendix"><a href="#git-quick-start">A. Git Quick Reference</a></span></dt><dd><dl><dt><span class="section"><a href="#quick-creating-a-new-repository">Creating a new repository</a></span></dt><dt><span class="section"><a href="#managing-branches">Managing branches</a></span></dt><dt><span class="section"><a href="#exploring-history">Exploring history</a></span></dt><dt><span class="section"><a href="#making-changes">Making changes</a></span></dt><dt><span class="section"><a href="#merging">Merging</a></span></dt><dt><span class="section"><a href="#sharing-your-changes">Sharing your changes</a></span></dt><dt><span class="section"><a href="#repository-maintenance">Repository maintenance</a></span></dt></dl></dd><dt><span class="appendix"><a href="#todo">B. Notes and todo list for this manual</a></span></dt></dl></div><p>Git is a fast distributed revision control system.</p><p>This manual is designed to be readable by someone with basic UNIX
command-line skills, but no previous knowledge of Git.</p><p><a class="xref" href="#repositories-and-branches" title="Chapter 1. Repositories and Branches">Chapter 1, <i>Repositories and Branches</i></a> and <a class="xref" href="#exploring-git-history" title="Chapter 2. Exploring Git history">Chapter 2, <i>Exploring Git history</i></a> explain how
to fetch and study a project using git—read these chapters to learn how
to build and test a particular version of a software project, search for
@@ -100,7 +100,7 @@
each parent representing the most recent commit on one of the lines
of development leading to that point.</p><p>The best way to see how this works is using the <a class="ulink" href="gitk.html" target="_top">gitk(1)</a>
command; running gitk now on a Git repository and looking for merge
-commits will help understand how the Git organizes history.</p><p>In the following, we say that commit X is "reachable" from commit Y
+commits will help understand how Git organizes history.</p><p>In the following, we say that commit X is "reachable" from commit Y
if commit X is an ancestor of commit Y. Equivalently, you could say
that Y is a descendant of X, or that there is a chain of parents
leading from commit Y to commit X.</p></div><div class="section" title="Understanding history: History diagrams"><div class="titlepage"><div><div><h3 class="title"><a name="history-diagrams"></a>Understanding history: History diagrams</h3></div></div></div><p>We will sometimes represent Git history using diagrams like the one
@@ -120,37 +120,33 @@
a summary of the commands:</p><div class="variablelist"><dl><dt><span class="term">
<code class="literal">git branch</code>
</span></dt><dd>
- list all branches
+ list all branches.
</dd><dt><span class="term">
<code class="literal">git branch &lt;branch&gt;</code>
</span></dt><dd>
create a new branch named <code class="literal">&lt;branch&gt;</code>, referencing the same
- point in history as the current branch
+ point in history as the current branch.
</dd><dt><span class="term">
<code class="literal">git branch &lt;branch&gt; &lt;start-point&gt;</code>
</span></dt><dd>
create a new branch named <code class="literal">&lt;branch&gt;</code>, referencing
<code class="literal">&lt;start-point&gt;</code>, which may be specified any way you like,
- including using a branch name or a tag name
+ including using a branch name or a tag name.
</dd><dt><span class="term">
<code class="literal">git branch -d &lt;branch&gt;</code>
</span></dt><dd>
- delete the branch <code class="literal">&lt;branch&gt;</code>; if the branch you are deleting
- points to a commit which is not reachable from the current
- branch, this command will fail with a warning.
+ delete the branch <code class="literal">&lt;branch&gt;</code>; if the branch is not fully
+ merged in its upstream branch or contained in the current branch,
+ this command will fail with a warning.
</dd><dt><span class="term">
<code class="literal">git branch -D &lt;branch&gt;</code>
</span></dt><dd>
- even if the branch points to a commit not reachable
- from the current branch, you may know that that commit
- is still reachable from some other branch or tag. In that
- case it is safe to use this command to force Git to delete
- the branch.
+ delete the branch <code class="literal">&lt;branch&gt;</code> irrespective of its merged status.
</dd><dt><span class="term">
<code class="literal">git checkout &lt;branch&gt;</code>
</span></dt><dd>
make the current branch <code class="literal">&lt;branch&gt;</code>, updating the working
- directory to reflect the version referenced by <code class="literal">&lt;branch&gt;</code>
+ directory to reflect the version referenced by <code class="literal">&lt;branch&gt;</code>.
</dd><dt><span class="term">
<code class="literal">git checkout -b &lt;new&gt; &lt;start-point&gt;</code>
</span></dt><dd>
@@ -162,15 +158,22 @@
ref: refs/heads/master</pre></div><div class="section" title="Examining an old version without creating a new branch"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="detached-head"></a>Examining an old version without creating a new branch</h2></div></div></div><p>The <code class="literal">git checkout</code> command normally expects a branch head, but will also
accept an arbitrary commit; for example, you can check out the commit
referenced by a tag:</p><pre class="literallayout">$ git checkout v2.6.17
-Note: moving to "v2.6.17" which isn't a local branch
-If you want to create a new branch from this checkout, you may do so
-(now or later) by using -b with the checkout command again. Example:
- git checkout -b &lt;new_branch_name&gt;
+Note: checking out 'v2.6.17'.
+
+You are in 'detached HEAD' state. You can look around, make experimental
+changes and commit them, and you can discard any commits you make in this
+state without impacting any branches by performing another checkout.
+
+If you want to create a new branch to retain commits you create, you may
+do so (now or later) by using -b with the checkout command again. Example:
+
+ git checkout -b new_branch_name
+
HEAD is now at 427abfa... Linux v2.6.17</pre><p>The HEAD then refers to the SHA-1 of the commit instead of to a branch,
and git branch shows that you are no longer on a branch:</p><pre class="literallayout">$ cat .git/HEAD
427abfa28afedffadfca9dd8b067eb6d36bac53f
$ git branch
-* (no branch)
+* (detached from v2.6.17)
master</pre><p>In this case we say that the HEAD is "detached".</p><p>This is an easy way to check out a particular version without having to
make up a name for the new branch. You can still create a new branch
(or tag) for this version later if you decide to.</p></div><div class="section" title="Examining branches from a remote repository"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="examining-remote-branches"></a>Examining branches from a remote repository</h2></div></div></div><p>The "master" branch that was created at the time you cloned is a copy
@@ -348,12 +351,12 @@
e05db0fd4f31dde7005f075a84f96b360d05984b
$ git rev-list master
e05db0fd4f31dde7005f075a84f96b360d05984b</pre><p>Or you could recall that the <code class="literal">...</code> operator selects all commits
-contained reachable from either one reference or the other but not
+reachable from either one reference or the other but not
both; so</p><pre class="literallayout">$ git log origin...master</pre><p>will return no commits when the two branches are equal.</p></div><div class="section" title="Find first tagged version including a given fix"><div class="titlepage"><div><div><h3 class="title"><a name="finding-tagged-descendants"></a>Find first tagged version including a given fix</h3></div></div></div><p>Suppose you know that the commit e05db0fd fixed a certain problem.
You’d like to find the earliest tagged release that contains that
fix.</p><p>Of course, there may be more than one answer—if the history branched
after commit e05db0fd, then there could be multiple "earliest" tagged
-releases.</p><p>You could just visually inspect the commits since e05db0fd:</p><pre class="literallayout">$ gitk e05db0fd..</pre><p>Or you can use <a class="ulink" href="git-name-rev.html" target="_top">git-name-rev(1)</a>, which will give the commit a
+releases.</p><p>You could just visually inspect the commits since e05db0fd:</p><pre class="literallayout">$ gitk e05db0fd..</pre><p>or you can use <a class="ulink" href="git-name-rev.html" target="_top">git-name-rev(1)</a>, which will give the commit a
name based on any tag it finds pointing to one of the commit’s
descendants:</p><pre class="literallayout">$ git name-rev --tags e05db0fd
e05db0fd tags/v1.5.0-rc1^0~23</pre><p>The <a class="ulink" href="git-describe.html" target="_top">git-describe(1)</a> command does the opposite, naming the
@@ -367,16 +370,16 @@
actually is an ancestor of v1.5.0-rc1.</p><p>Alternatively, note that</p><pre class="literallayout">$ git log v1.5.0-rc1..e05db0fd</pre><p>will produce empty output if and only if v1.5.0-rc1 includes e05db0fd,
because it outputs only commits that are not reachable from v1.5.0-rc1.</p><p>As yet another alternative, the <a class="ulink" href="git-show-branch.html" target="_top">git-show-branch(1)</a> command lists
the commits reachable from its arguments with a display on the left-hand
-side that indicates which arguments that commit is reachable from. So,
-you can run something like</p><pre class="literallayout">$ git show-branch e05db0fd v1.5.0-rc0 v1.5.0-rc1 v1.5.0-rc2
+side that indicates which arguments that commit is reachable from.
+So, if you run something like</p><pre class="literallayout">$ git show-branch e05db0fd v1.5.0-rc0 v1.5.0-rc1 v1.5.0-rc2
! [e05db0fd] Fix warnings in sha1_file.c - use C99 printf format if
available
! [v1.5.0-rc0] GIT v1.5.0 preview
! [v1.5.0-rc1] GIT v1.5.0-rc1
! [v1.5.0-rc2] GIT v1.5.0-rc2
-...</pre><p>then search for a line that looks like</p><pre class="literallayout">+ ++ [e05db0fd] Fix warnings in sha1_file.c - use C99 printf format if
-available</pre><p>Which shows that e05db0fd is reachable from itself, from v1.5.0-rc1, and
-from v1.5.0-rc2, but not from v1.5.0-rc0.</p></div><div class="section" title="Showing commits unique to a given branch"><div class="titlepage"><div><div><h3 class="title"><a name="showing-commits-unique-to-a-branch"></a>Showing commits unique to a given branch</h3></div></div></div><p>Suppose you would like to see all the commits reachable from the branch
+...</pre><p>then a line like</p><pre class="literallayout">+ ++ [e05db0fd] Fix warnings in sha1_file.c - use C99 printf format if
+available</pre><p>shows that e05db0fd is reachable from itself, from v1.5.0-rc1,
+and from v1.5.0-rc2, and not from v1.5.0-rc0.</p></div><div class="section" title="Showing commits unique to a given branch"><div class="titlepage"><div><div><h3 class="title"><a name="showing-commits-unique-to-a-branch"></a>Showing commits unique to a given branch</h3></div></div></div><p>Suppose you would like to see all the commits reachable from the branch
head named <code class="literal">master</code> but not from any other head in your repository.</p><p>We can list all the heads in this repository with
<a class="ulink" href="git-show-ref.html" target="_top">git-show-ref(1)</a>:</p><pre class="literallayout">$ git show-ref --heads
bf62196b5e363d73353a9dcf094c59595f3153b7 refs/heads/core-tutorial
@@ -442,7 +445,7 @@
special staging area called "the index."</p><p>At the beginning, the content of the index will be identical to
that of the HEAD. The command <code class="literal">git diff --cached</code>, which shows
the difference between the HEAD and the index, should therefore
-produce no output at that point.</p><p>Modifying the index is easy:</p><p>To update the index with the new contents of a modified file, use</p><pre class="literallayout">$ git add path/to/file</pre><p>To add the contents of a new file to the index, use</p><pre class="literallayout">$ git add path/to/file</pre><p>To remove a file from the index and from the working tree,</p><pre class="literallayout">$ git rm path/to/file</pre><p>After each step you can verify that</p><pre class="literallayout">$ git diff --cached</pre><p>always shows the difference between the HEAD and the index file—this
+produce no output at that point.</p><p>Modifying the index is easy:</p><p>To update the index with the contents of a new or modified file, use</p><pre class="literallayout">$ git add path/to/file</pre><p>To remove a file from the index and from the working tree, use</p><pre class="literallayout">$ git rm path/to/file</pre><p>After each step you can verify that</p><pre class="literallayout">$ git diff --cached</pre><p>always shows the difference between the HEAD and the index file—this
is what you’d commit if you created the commit now—and that</p><pre class="literallayout">$ git diff</pre><p>shows the difference between the working tree and the index file.</p><p>Note that <code class="literal">git add</code> always adds just the current contents of a file
to the index; further changes to the same file will be ignored unless
you run <code class="literal">git add</code> on the file again.</p><p>When you’re ready, just run</p><pre class="literallayout">$ git commit</pre><p>and Git will prompt you for a commit message and then create the new
@@ -716,7 +719,7 @@
updated to point to the latest commit from the upstream branch.)</p><p>The <code class="literal">git pull</code> command can also be given <code class="literal">.</code> as the "remote" repository,
in which case it just merges in a branch from the current repository; so
the commands</p><pre class="literallayout">$ git pull . branch
-$ git merge branch</pre><p>are roughly equivalent. The former is actually very commonly used.</p></div><div class="section" title="Submitting patches to a project"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="submitting-patches"></a>Submitting patches to a project</h2></div></div></div><p>If you just have a few changes, the simplest way to submit them may
+$ git merge branch</pre><p>are roughly equivalent.</p></div><div class="section" title="Submitting patches to a project"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="submitting-patches"></a>Submitting patches to a project</h2></div></div></div><p>If you just have a few changes, the simplest way to submit them may
just be to send them as patches in email:</p><p>First, use <a class="ulink" href="git-format-patch.html" target="_top">git-format-patch(1)</a>; for example:</p><pre class="literallayout">$ git format-patch origin</pre><p>will produce a numbered series of files in the current directory, one
for each patch in the current branch but not in <code class="literal">origin/HEAD</code>.</p><p><code class="literal">git format-patch</code> can include an initial "cover letter". You can insert
commentary on individual patches after the three dash line which
@@ -788,7 +791,7 @@
$ mv hooks/post-update.sample hooks/post-update</pre><p>(For an explanation of the last two lines, see
<a class="ulink" href="git-update-server-info.html" target="_top">git-update-server-info(1)</a> and <a class="ulink" href="githooks.html" target="_top">githooks(5)</a>.)</p><p>Advertise the URL of <code class="literal">proj.git</code>. Anybody else should then be able to
clone or pull from that URL, for example with a command line like:</p><pre class="literallayout">$ git clone http://yourserver.com/~you/proj.git</pre><p>(See also
-<a class="ulink" href="howto/setup-git-server-over-http.txt" target="_top">setup-git-server-over-http</a>
+<a class="ulink" href="howto/setup-git-server-over-http.html" target="_top">setup-git-server-over-http</a>
for a slightly more sophisticated setup using WebDAV which also
allows pushing over HTTP.)</p></div><div class="section" title="Pushing changes to a public repository"><div class="titlepage"><div><div><h3 class="title"><a name="pushing-changes-to-a-public-repository"></a>Pushing changes to a public repository</h3></div></div></div><p>Note that the two techniques outlined above (exporting via
<a class="link" href="#exporting-via-http" title="Exporting a git repository via HTTP">http</a> or <a class="link" href="#exporting-via-git" title="Exporting a Git repository via the Git protocol">git</a>) allow other
@@ -904,12 +907,12 @@
tested changes
2) help future bug hunters that use <code class="literal">git bisect</code> to find problems</p><pre class="literallayout">$ git checkout -b speed-up-spinlocks v2.6.35</pre><p>Now you apply the patch(es), run some tests, and commit the change(s). If
the patch is a multi-part series, then you should apply each as a separate
-commit to this branch.</p><pre class="literallayout">$ ... patch ... test ... commit [ ... patch ... test ... commit ]*</pre><p>When you are happy with the state of this change, you can pull it into the
-"test" branch in preparation to make it public:</p><pre class="literallayout">$ git checkout test &amp;&amp; git pull . speed-up-spinlocks</pre><p>It is unlikely that you would have any conflicts here … but you might if you
+commit to this branch.</p><pre class="literallayout">$ ... patch ... test ... commit [ ... patch ... test ... commit ]*</pre><p>When you are happy with the state of this change, you can merge it into the
+"test" branch in preparation to make it public:</p><pre class="literallayout">$ git checkout test &amp;&amp; git merge speed-up-spinlocks</pre><p>It is unlikely that you would have any conflicts here … but you might if you
spent a while on this step and had also pulled new versions from upstream.</p><p>Some time later when enough time has passed and testing done, you can pull the
same branch into the <code class="literal">release</code> tree ready to go upstream. This is where you
see the value of keeping each patch (or patch series) in its own branch. It
-means that the patches can be moved into the <code class="literal">release</code> tree in any order.</p><pre class="literallayout">$ git checkout release &amp;&amp; git pull . speed-up-spinlocks</pre><p>After a while, you will have a number of branches, and despite the
+means that the patches can be moved into the <code class="literal">release</code> tree in any order.</p><pre class="literallayout">$ git checkout release &amp;&amp; git merge speed-up-spinlocks</pre><p>After a while, you will have a number of branches, and despite the
well chosen names you picked for each of them, you may forget what
they are for, or what status they are in. To get a reminder of what
changes are in a specific branch, use:</p><pre class="literallayout">$ git log linux..branchname | git shortlog</pre><p>To see whether it has already been merged into the test or release branches,
@@ -1376,15 +1379,13 @@
those "loose" objects.</p><p>You can save space and make Git faster by moving these loose objects in
to a "pack file", which stores a group of objects in an efficient
compressed format; the details of how pack files are formatted can be
-found in <a class="ulink" href="technical/pack-format.txt" target="_top">technical/pack-format.txt</a>.</p><p>To put the loose objects into a pack, just run git repack:</p><pre class="literallayout">$ git repack
-Generating pack...
-Done counting 6020 objects.
-Deltifying 6020 objects.
- 100% (6020/6020) done
-Writing 6020 objects.
- 100% (6020/6020) done
-Total 6020, written 6020 (delta 4070), reused 0 (delta 0)
-Pack pack-3e54ad29d5b2e05838c75df582c65257b8d08e1c created.</pre><p>You can then run</p><pre class="literallayout">$ git prune</pre><p>to remove any of the "loose" objects that are now contained in the
+found in <a class="ulink" href="technical/pack-format.html" target="_top">pack format</a>.</p><p>To put the loose objects into a pack, just run git repack:</p><pre class="literallayout">$ git repack
+Counting objects: 6020, done.
+Delta compression using up to 4 threads.
+Compressing objects: 100% (6020/6020), done.
+Writing objects: 100% (6020/6020), done.
+Total 6020 (delta 4070), reused 0 (delta 0)</pre><p>This creates a single "pack file" in .git/objects/pack/
+containing all currently unpacked objects. You can then run</p><pre class="literallayout">$ git prune</pre><p>to remove any of the "loose" objects that are now contained in the
pack. This will also remove any unreferenced objects (which may be
created when, for example, you use <code class="literal">git reset</code> to remove a commit).
You can verify that the loose objects are gone by looking at the
@@ -1424,15 +1425,11 @@
because you interrupted a <code class="literal">git fetch</code> with ^C or something like that,
leaving <span class="emphasis"><em>some</em></span> of the new objects in the object database, but just
dangling and useless.</p><p>Anyway, once you are sure that you’re not interested in any dangling
-state, you can just prune all unreachable objects:</p><pre class="literallayout">$ git prune</pre><p>and they’ll be gone. But you should only run <code class="literal">git prune</code> on a quiescent
+state, you can just prune all unreachable objects:</p><pre class="literallayout">$ git prune</pre><p>and they’ll be gone. (You should only run <code class="literal">git prune</code> on a quiescent
repository—it’s kind of like doing a filesystem fsck recovery: you
-don’t want to do that while the filesystem is mounted.</p><p>(The same is true of <code class="literal">git fsck</code> itself, btw, but since
-<code class="literal">git fsck</code> never actually <span class="strong"><strong>changes</strong></span> the repository, it just reports
-on what it found, <code class="literal">git fsck</code> itself is never <span class="emphasis"><em>dangerous</em></span> to run.
-Running it while somebody is actually changing the repository can cause
-confusing and scary messages, but it won’t actually do anything bad. In
-contrast, running <code class="literal">git prune</code> while somebody is actively changing the
-repository is a <span class="strong"><strong>BAD</strong></span> idea).</p></div><div class="section" title="Recovering from repository corruption"><div class="titlepage"><div><div><h3 class="title"><a name="recovering-from-repository-corruption"></a>Recovering from repository corruption</h3></div></div></div><p>By design, Git treats data trusted to it with caution. However, even in
+don’t want to do that while the filesystem is mounted.
+<code class="literal">git prune</code> is designed not to cause any harm in such cases of concurrent
+accesses to a repository but you might receive confusing or scary messages.)</p></div><div class="section" title="Recovering from repository corruption"><div class="titlepage"><div><div><h3 class="title"><a name="recovering-from-repository-corruption"></a>Recovering from repository corruption</h3></div></div></div><p>By design, Git treats data trusted to it with caution. However, even in
the absence of bugs in Git itself, it is still possible that hardware or
operating system errors could corrupt data.</p><p>The first defense against such problems is backups. You can back up a
Git directory using clone, or just using cp, tar, or any other backup
@@ -1547,7 +1544,7 @@
clone none, some or all of the submodules.</p><p>The <a class="ulink" href="git-submodule.html" target="_top">git-submodule(1)</a> command is available since Git 1.5.3. Users
with Git 1.5.2 can look up the submodule commits in the repository and
manually check them out; earlier versions won’t recognize the submodules at
-all.</p><p>To see how submodule support works, create (for example) four example
+all.</p><p>To see how submodule support works, create four example
repositories that can be used later as a submodule:</p><pre class="literallayout">$ mkdir ~/git
$ cd ~/git
$ for i in a b c d
@@ -1594,7 +1591,7 @@
that <code class="literal">git submodule update</code> checks out a specific commit, rather than the tip
of a branch. It’s like checking out a tag: the head is detached, so you’re not
working on a branch.</p><pre class="literallayout">$ git branch
-* (no branch)
+* (detached from d266b98)
master</pre><p>If you want to make a change within a submodule and you have a detached head,
then you should create or checkout a branch, make your changes, publish the
change within the submodule, and then update the superproject to reference the
@@ -1717,7 +1714,7 @@
or more parent commits, in which case we call it a "merge", due to the
fact that such a commit brings together ("merges") two or more
previous states represented by other commits.</p><p>In other words, while a "tree" represents a particular directory state
-of a working directory, a "commit" represents that state in "time",
+of a working directory, a "commit" represents that state in time,
and explains how we got there.</p><p>You create a commit object by giving it the tree that describes the
state at the time of the commit, and a list of parents:</p><pre class="literallayout">$ git commit-tree &lt;tree&gt; -p &lt;parent&gt; [(-p &lt;parent2&gt;)...]</pre><p>and then giving the reason for the commit on stdin (either through
redirection from a pipe or file, or by just typing it at the tty).</p><p><code class="literal">git commit-tree</code> will return the name of the object that represents
@@ -1725,8 +1722,7 @@
you’d commit a new <code class="literal">HEAD</code> state, and while Git doesn’t care where you
save the note about that state, in practice we tend to just write the
result to the file pointed at by <code class="literal">.git/HEAD</code>, so that we can always see
-what the last committed state was.</p><p>Here is an ASCII art by Jon Loeliger that illustrates how
-various pieces fit together.</p><pre class="literallayout"> commit-tree
+what the last committed state was.</p><p>Here is a picture that illustrates how various pieces fit together:</p><pre class="literallayout"> commit-tree
commit obj
+----+
| |
@@ -1766,17 +1762,16 @@
readable form.</p><p>It’s especially instructive to look at "commit" objects, since those
tend to be small and fairly self-explanatory. In particular, if you
follow the convention of having the top commit name in <code class="literal">.git/HEAD</code>,
-you can do</p><pre class="literallayout">$ git cat-file commit HEAD</pre><p>to see what the top commit was.</p></div><div class="section" title="Merging multiple trees"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="merging-multiple-trees"></a>Merging multiple trees</h2></div></div></div><p>Git helps you do a three-way merge, which you can expand to n-way by
-repeating the merge procedure arbitrary times until you finally
-"commit" the state. The normal situation is that you’d only do one
-three-way merge (two parents), and commit it, but if you like to, you
-can do multiple parents in one go.</p><p>To do a three-way merge, you need the two sets of "commit" objects
-that you want to merge, use those to find the closest common parent (a
-third "commit" object), and then use those commit objects to find the
-state of the directory ("tree" object) at these points.</p><p>To get the "base" for the merge, you first look up the common parent
-of two commits with</p><pre class="literallayout">$ git merge-base &lt;commit1&gt; &lt;commit2&gt;</pre><p>which will return you the commit they are both based on. You should
-now look up the "tree" objects of those commits, which you can easily
-do with (for example)</p><pre class="literallayout">$ git cat-file commit &lt;commitname&gt; | head -1</pre><p>since the tree object information is always the first line in a commit
+you can do</p><pre class="literallayout">$ git cat-file commit HEAD</pre><p>to see what the top commit was.</p></div><div class="section" title="Merging multiple trees"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="merging-multiple-trees"></a>Merging multiple trees</h2></div></div></div><p>Git can help you perform a three-way merge, which can in turn be
+used for a many-way merge by repeating the merge procedure several
+times. The usual situation is that you only do one three-way merge
+(reconciling two lines of history) and commit the result, but if
+you like to, you can merge several branches in one go.</p><p>To perform a three-way merge, you start with the two commits you
+want to merge, find their closest common parent (a third commit),
+and compare the trees corresponding to these three commits.</p><p>To get the "base" for the merge, look up the common parent of two
+commits:</p><pre class="literallayout">$ git merge-base &lt;commit1&gt; &lt;commit2&gt;</pre><p>This prints the name of a commit they are both based on. You should
+now look up the tree objects of those commits, which you can easily
+do with</p><pre class="literallayout">$ git cat-file commit &lt;commitname&gt; | head -1</pre><p>since the tree object information is always the first line in a commit
object.</p><p>Once you know the three trees you are going to merge (the one "original"
tree, aka the common tree, and the two "result" trees, aka the branches
you want to merge), you do a "merge" read into the index. This will
@@ -1830,9 +1825,7 @@
about the data in the object. It’s worth noting that the SHA-1 hash
that is used to name the object is the hash of the original data
plus this header, so <code class="literal">sha1sum</code> <span class="emphasis"><em>file</em></span> does not match the object name
-for <span class="emphasis"><em>file</em></span>.
-(Historical note: in the dawn of the age of Git the hash
-was the SHA-1 of the <span class="emphasis"><em>compressed</em></span> object.)</p><p>As a result, the general consistency of an object can always be tested
+for <span class="emphasis"><em>file</em></span>.</p><p>As a result, the general consistency of an object can always be tested
independently of the contents or the type of the object: all objects can
be validated by verifying that (a) their hashes match the content of the
file and (b) the object successfully inflates to a stream of bytes that
@@ -2035,6 +2028,19 @@
to the top <a class="link" href="#def_directory">directory</a> of the stored
revision.
</dd><dt><span class="term">
+<a name="def_commit-ish"></a>commit-ish (also committish)
+</span></dt><dd>
+ A <a class="link" href="#def_commit_object">commit object</a> or an
+ <a class="link" href="#def_object">object</a> that can be recursively dereferenced to
+ a commit object.
+ The following are all commit-ishes:
+ a commit object,
+ a <a class="link" href="#def_tag_object">tag object</a> that points to a commit
+ object,
+ a tag object that points to a tag object that points to a
+ commit object,
+ etc.
+</dd><dt><span class="term">
<a name="def_core_git"></a>core Git
</span></dt><dd>
Fundamental data structures and utilities of Git. Exposes only limited
@@ -2397,12 +2403,18 @@
to the result.
</dd><dt><span class="term">
<a name="def_ref"></a>ref
-</span></dt><dd>
- A 40-byte hex representation of a <a class="link" href="#def_SHA1">SHA-1</a> or a name that
- denotes a particular <a class="link" href="#def_object">object</a>. They may be stored in
- a file under <code class="literal">$GIT_DIR/refs/</code> directory, or
- in the <code class="literal">$GIT_DIR/packed-refs</code> file.
-</dd><dt><span class="term">
+</span></dt><dd><p class="simpara">
+ A name that begins with <code class="literal">refs/</code> (e.g. <code class="literal">refs/heads/master</code>)
+ that points to an <a class="link" href="#def_object_name">object name</a> or another
+ ref (the latter is called a <a class="link" href="#def_symref">symbolic ref</a>).
+ For convenience, a ref can sometimes be abbreviated when used
+ as an argument to a Git command; see <a class="ulink" href="gitrevisions.html" target="_top">gitrevisions(7)</a>
+ for details.
+ Refs are stored in the <a class="link" href="#def_repository">repository</a>.
+</p><p class="simpara">The ref namespace is hierarchical.
+Different subhierarchies are used for different purposes (e.g. the
+<code class="literal">refs/heads/</code> hierarchy is used to represent local branches).</p><p class="simpara">There are a few special-purpose refs that do not begin with <code class="literal">refs/</code>.
+The most notable example is <code class="literal">HEAD</code>.</p></dd><dt><span class="term">
<a name="def_reflog"></a>reflog
</span></dt><dd>
A reflog shows the local "history" of a ref. In other words,
@@ -2515,9 +2527,20 @@
with refs to the associated blob and/or tree objects. A
<a class="link" href="#def_tree">tree</a> is equivalent to a <a class="link" href="#def_directory">directory</a>.
</dd><dt><span class="term">
-<a name="def_tree-ish"></a>tree-ish
-</span></dt><dd>
- A <a class="link" href="#def_ref">ref</a> pointing to either a <a class="link" href="#def_commit_object">commit object</a>, a <a class="link" href="#def_tree_object">tree object</a>, or a <a class="link" href="#def_tag_object">tag object</a> pointing to a tag or commit or tree object.
+<a name="def_tree-ish"></a>tree-ish (also treeish)
+</span></dt><dd>
+ A <a class="link" href="#def_tree_object">tree object</a> or an <a class="link" href="#def_object">object</a>
+ that can be recursively dereferenced to a tree object.
+ Dereferencing a <a class="link" href="#def_commit_object">commit object</a> yields the
+ tree object corresponding to the <a class="link" href="#def_revision">revision</a>'s
+ top <a class="link" href="#def_directory">directory</a>.
+ The following are all tree-ishes:
+ a <a class="link" href="#def_commit-ish">commit-ish</a>,
+ a tree object,
+ a <a class="link" href="#def_tag_object">tag object</a> that points to a tree object,
+ a tag object that points to a tag object that points to a tree
+ object,
+ etc.
</dd><dt><span class="term">
<a name="def_unmerged_index"></a>unmerged index
</span></dt><dd>
146 user-manual.txt
View
@@ -1,6 +1,5 @@
-Git User's Manual (for version 1.5.3 or newer)
-______________________________________________
-
+Git User Manual
+_______________
Git is a fast distributed revision control system.
@@ -220,7 +219,7 @@ of development leading to that point.
The best way to see how this works is using the linkgit:gitk[1]
command; running gitk now on a Git repository and looking for merge
-commits will help understand how the Git organizes history.
+commits will help understand how Git organizes history.
In the following, we say that commit X is "reachable" from commit Y
if commit X is an ancestor of commit Y. Equivalently, you could say
@@ -269,27 +268,23 @@ Creating, deleting, and modifying branches is quick and easy; here's
a summary of the commands:
`git branch`::
- list all branches
+ list all branches.
`git branch <branch>`::
create a new branch named `<branch>`, referencing the same
- point in history as the current branch
+ point in history as the current branch.
`git branch <branch> <start-point>`::
create a new branch named `<branch>`, referencing
`<start-point>`, which may be specified any way you like,
- including using a branch name or a tag name
+ including using a branch name or a tag name.
`git branch -d <branch>`::
- delete the branch `<branch>`; if the branch you are deleting
- points to a commit which is not reachable from the current
- branch, this command will fail with a warning.
+ delete the branch `<branch>`; if the branch is not fully
+ merged in its upstream branch or contained in the current branch,
+ this command will fail with a warning.
`git branch -D <branch>`::
- even if the branch points to a commit not reachable
- from the current branch, you may know that that commit
- is still reachable from some other branch or tag. In that
- case it is safe to use this command to force Git to delete
- the branch.
+ delete the branch `<branch>` irrespective of its merged status.
`git checkout <branch>`::
make the current branch `<branch>`, updating the working
- directory to reflect the version referenced by `<branch>`
+ directory to reflect the version referenced by `<branch>`.
`git checkout -b <new> <start-point>`::
create a new branch `<new>` referencing `<start-point>`, and
check it out.
@@ -313,10 +308,17 @@ referenced by a tag:
------------------------------------------------
$ git checkout v2.6.17
-Note: moving to "v2.6.17" which isn't a local branch
-If you want to create a new branch from this checkout, you may do so
-(now or later) by using -b with the checkout command again. Example:
- git checkout -b <new_branch_name>
+Note: checking out 'v2.6.17'.
+
+You are in 'detached HEAD' state. You can look around, make experimental
+changes and commit them, and you can discard any commits you make in this
+state without impacting any branches by performing another checkout.
+
+If you want to create a new branch to retain commits you create, you may
+do so (now or later) by using -b with the checkout command again. Example:
+
+ git checkout -b new_branch_name
+
HEAD is now at 427abfa... Linux v2.6.17
------------------------------------------------
@@ -327,7 +329,7 @@ and git branch shows that you are no longer on a branch:
$ cat .git/HEAD
427abfa28afedffadfca9dd8b067eb6d36bac53f
$ git branch
-* (no branch)
+* (detached from v2.6.17)
master
------------------------------------------------
@@ -787,7 +789,7 @@ e05db0fd4f31dde7005f075a84f96b360d05984b
-------------------------------------------------
Or you could recall that the `...` operator selects all commits
-contained reachable from either one reference or the other but not
+reachable from either one reference or the other but not
both; so
-------------------------------------------------
@@ -814,7 +816,7 @@ You could just visually inspect the commits since e05db0fd:
$ gitk e05db0fd..
-------------------------------------------------
-Or you can use linkgit:git-name-rev[1], which will give the commit a
+or you can use linkgit:git-name-rev[1], which will give the commit a
name based on any tag it finds pointing to one of the commit's
descendants:
@@ -858,8 +860,8 @@ because it outputs only commits that are not reachable from v1.5.0-rc1.
As yet another alternative, the linkgit:git-show-branch[1] command lists
the commits reachable from its arguments with a display on the left-hand
-side that indicates which arguments that commit is reachable from. So,
-you can run something like
+side that indicates which arguments that commit is reachable from.
+So, if you run something like
-------------------------------------------------
$ git show-branch e05db0fd v1.5.0-rc0 v1.5.0-rc1 v1.5.0-rc2
@@ -871,15 +873,15 @@ available
...
-------------------------------------------------
-then search for a line that looks like
+then a line like
-------------------------------------------------
+ ++ [e05db0fd] Fix warnings in sha1_file.c - use C99 printf format if
available
-------------------------------------------------
-Which shows that e05db0fd is reachable from itself, from v1.5.0-rc1, and
-from v1.5.0-rc2, but not from v1.5.0-rc0.
+shows that e05db0fd is reachable from itself, from v1.5.0-rc1,
+and from v1.5.0-rc2, and not from v1.5.0-rc0.
[[showing-commits-unique-to-a-branch]]
Showing commits unique to a given branch
@@ -1074,19 +1076,13 @@ produce no output at that point.
Modifying the index is easy:
-To update the index with the new contents of a modified file, use
-
--------------------------------------------------
-$ git add path/to/file
--------------------------------------------------
-
-To add the contents of a new file to the index, use
+To update the index with the contents of a new or modified file, use
-------------------------------------------------
$ git add path/to/file
-------------------------------------------------
-To remove a file from the index and from the working tree,
+To remove a file from the index and from the working tree, use
-------------------------------------------------
$ git rm path/to/file
@@ -1787,7 +1783,7 @@ $ git pull . branch
$ git merge branch
-------------------------------------------------
-are roughly equivalent. The former is actually very commonly used.
+are roughly equivalent.
[[submitting-patches]]
Submitting patches to a project
@@ -1977,7 +1973,7 @@ $ git clone http://yourserver.com/~you/proj.git
-------------------------------------------------
(See also
-link:howto/setup-git-server-over-http.txt[setup-git-server-over-http]
+link:howto/setup-git-server-over-http.html[setup-git-server-over-http]
for a slightly more sophisticated setup using WebDAV which also
allows pushing over HTTP.)
@@ -2249,11 +2245,11 @@ commit to this branch.
$ ... patch ... test ... commit [ ... patch ... test ... commit ]*
-------------------------------------------------
-When you are happy with the state of this change, you can pull it into the
+When you are happy with the state of this change, you can merge it into the
"test" branch in preparation to make it public:
-------------------------------------------------
-$ git checkout test && git pull . speed-up-spinlocks
+$ git checkout test && git merge speed-up-spinlocks
-------------------------------------------------
It is unlikely that you would have any conflicts here ... but you might if you
@@ -2265,7 +2261,7 @@ see the value of keeping each patch (or patch series) in its own branch. It
means that the patches can be moved into the `release` tree in any order.
-------------------------------------------------
-$ git checkout release && git pull . speed-up-spinlocks
+$ git checkout release && git merge speed-up-spinlocks
-------------------------------------------------
After a while, you will have a number of branches, and despite the
@@ -3191,23 +3187,21 @@ those "loose" objects.
You can save space and make Git faster by moving these loose objects in
to a "pack file", which stores a group of objects in an efficient
compressed format; the details of how pack files are formatted can be
-found in link:technical/pack-format.txt[technical/pack-format.txt].
+found in link:technical/pack-format.html[pack format].
To put the loose objects into a pack, just run git repack:
------------------------------------------------
$ git repack
-Generating pack...
-Done counting 6020 objects.
-Deltifying 6020 objects.
- 100% (6020/6020) done
-Writing 6020 objects.
- 100% (6020/6020) done
-Total 6020, written 6020 (delta 4070), reused 0 (delta 0)
-Pack pack-3e54ad29d5b2e05838c75df582c65257b8d08e1c created.
+Counting objects: 6020, done.
+Delta compression using up to 4 threads.
+Compressing objects: 100% (6020/6020), done.
+Writing objects: 100% (6020/6020), done.
+Total 6020 (delta 4070), reused 0 (delta 0)
------------------------------------------------
-You can then run
+This creates a single "pack file" in .git/objects/pack/
+containing all currently unpacked objects. You can then run
------------------------------------------------
$ git prune
@@ -3305,17 +3299,11 @@ state, you can just prune all unreachable objects:
$ git prune
------------------------------------------------
-and they'll be gone. But you should only run `git prune` on a quiescent
+and they'll be gone. (You should only run `git prune` on a quiescent
repository--it's kind of like doing a filesystem fsck recovery: you
don't want to do that while the filesystem is mounted.
-
-(The same is true of `git fsck` itself, btw, but since
-`git fsck` never actually *changes* the repository, it just reports
-on what it found, `git fsck` itself is never 'dangerous' to run.
-Running it while somebody is actually changing the repository can cause
-confusing and scary messages, but it won't actually do anything bad. In
-contrast, running `git prune` while somebody is actively changing the
-repository is a *BAD* idea).
+`git prune` is designed not to cause any harm in such cases of concurrent
+accesses to a repository but you might receive confusing or scary messages.)
[[recovering-from-repository-corruption]]
Recovering from repository corruption
@@ -3538,7 +3526,7 @@ with Git 1.5.2 can look up the submodule commits in the repository and
manually check them out; earlier versions won't recognize the submodules at
all.
-To see how submodule support works, create (for example) four example
+To see how submodule support works, create four example
repositories that can be used later as a submodule:
-------------------------------------------------
@@ -3640,7 +3628,7 @@ working on a branch.
-------------------------------------------------
$ git branch
-* (no branch)
+* (detached from d266b98)
master
-------------------------------------------------
@@ -3910,7 +3898,7 @@ fact that such a commit brings together ("merges") two or more
previous states represented by other commits.
In other words, while a "tree" represents a particular directory state
-of a working directory, a "commit" represents that state in "time",
+of a working directory, a "commit" represents that state in time,
and explains how we got there.
You create a commit object by giving it the tree that describes the
@@ -3930,8 +3918,7 @@ save the note about that state, in practice we tend to just write the
result to the file pointed at by `.git/HEAD`, so that we can always see
what the last committed state was.
-Here is an ASCII art by Jon Loeliger that illustrates how
-various pieces fit together.
+Here is a picture that illustrates how various pieces fit together:
------------
@@ -4010,27 +3997,26 @@ to see what the top commit was.
Merging multiple trees
----------------------
-Git helps you do a three-way merge, which you can expand to n-way by
-repeating the merge procedure arbitrary times until you finally
-"commit" the state. The normal situation is that you'd only do one
-three-way merge (two parents), and commit it, but if you like to, you
-can do multiple parents in one go.
+Git can help you perform a three-way merge, which can in turn be
+used for a many-way merge by repeating the merge procedure several
+times. The usual situation is that you only do one three-way merge
+(reconciling two lines of history) and commit the result, but if
+you like to, you can merge several branches in one go.
-To do a three-way merge, you need the two sets of "commit" objects
-that you want to merge, use those to find the closest common parent (a