diff options
| author | Junio C Hamano <junio@kernel.org> | 2010-08-13 02:46:36 +0000 |
|---|---|---|
| committer | Junio C Hamano <junio@kernel.org> | 2010-08-13 02:46:36 +0000 |
| commit | b5a296fa6d8cd1a703ce2eb6232e0bbc654bd2a2 (patch) | |
| tree | 2065b54e46f97f5b84d01f2d2a211651f1b4f1c7 /git-reset.html | |
| parent | e85e36f153c88b736470872f5f9fab52799a28f6 (diff) | |
| download | git-htmldocs-b5a296fa6d8cd1a703ce2eb6232e0bbc654bd2a2.tar.gz | |
Autogenerated HTML docs for v1.7.2.1-95-g3d045
Diffstat (limited to 'git-reset.html')
| -rw-r--r-- | git-reset.html | 427 |
1 files changed, 219 insertions, 208 deletions
diff --git a/git-reset.html b/git-reset.html index 7f459b326..145f31a41 100644 --- a/git-reset.html +++ b/git-reset.html @@ -321,37 +321,52 @@ git-reset(1) Manual Page <h2>SYNOPSIS</h2>
<div class="sectionbody">
<div class="verseblock">
-<div class="content"><em>git reset</em> [--mixed | --soft | --hard | --merge | --keep] [-q] [<commit>]
-<em>git reset</em> [-q] [<commit>] [--] <paths>…
-<em>git reset</em> --patch [<commit>] [--] [<paths>…]</div></div>
+<div class="content"><em>git reset</em> [-q] [<commit>] [--] <paths>…
+<em>git reset</em> --patch [<commit>] [--] [<paths>…]
+<em>git reset</em> [--soft | --mixed | --hard | --merge | --keep] [-q] [<commit>]</div></div>
</div>
<h2 id="_description">DESCRIPTION</h2>
<div class="sectionbody">
-<div class="para"><p>Sets the current head to the specified commit and optionally resets the
-index and working tree to match.</p></div>
-<div class="para"><p>This command is useful if you notice some small error in a recent
-commit (or set of commits) and want to redo that part without showing
-the undo in the history.</p></div>
-<div class="para"><p>If you want to undo a commit other than the latest on a branch,
-<a href="git-revert.html">git-revert(1)</a> is your friend.</p></div>
-<div class="para"><p>The second and third forms with <em>paths</em> and/or --patch are used to
-revert selected paths in the index from a given commit, without moving
-HEAD.</p></div>
-</div>
-<h2 id="_options">OPTIONS</h2>
-<div class="sectionbody">
+<div class="para"><p>In the first and second form, copy entries from <commit> to the index.
+In the third form, set the current branch to <commit>, optionally
+modifying index and worktree to match. The <commit> defaults to HEAD
+in all forms.</p></div>
<div class="vlist"><dl>
<dt>
---mixed
+<em>git reset</em> [-q] [<commit>] [--] <paths>…
</dt>
<dd>
<p>
- Resets the index but not the working tree (i.e., the changed files
- are preserved but not marked for commit) and reports what has not
- been updated. This is the default action.
+ This form resets the index entries for all <paths> to their
+ state at the <commit>. (It does not affect the worktree, nor
+ the current branch.)
</p>
+<div class="para"><p>This means that <tt>git reset <paths></tt> is the opposite of <tt>git add
+<paths></tt>.</p></div>
</dd>
<dt>
+<em>git reset</em> --patch|-p [<commit>] [--] [<paths>…]
+</dt>
+<dd>
+<p>
+ Interactively select hunks in the difference between the index
+ and <commit> (defaults to HEAD). The chosen hunks are applied
+ in reverse to the index.
+</p>
+<div class="para"><p>This means that <tt>git reset -p</tt> is the opposite of <tt>git add -p</tt> (see
+<a href="git-add.html">git-add(1)</a>).</p></div>
+</dd>
+<dt>
+<em>git reset</em> [--<mode>] [<commit>]
+</dt>
+<dd>
+<p>
+ This form points the current branch to <commit> and then
+ updates index and working tree according to <mode>, which must
+ be one of the following:
+</p>
+<div class="vlist"><dl>
+<dt>
--soft
</dt>
<dd>
@@ -363,6 +378,16 @@ HEAD.</p></div> </p>
</dd>
<dt>
+--mixed
+</dt>
+<dd>
+<p>
+ Resets the index but not the working tree (i.e., the changed files
+ are preserved but not marked for commit) and reports what has not
+ been updated. This is the default action.
+</p>
+</dd>
+<dt>
--hard
</dt>
<dd>
@@ -395,21 +420,15 @@ HEAD.</p></div> is aborted.
</p>
</dd>
-<dt>
--p
-</dt>
-<dt>
---patch
-</dt>
-<dd>
-<p>
- Interactively select hunks in the difference between the index
- and <commit> (defaults to HEAD). The chosen hunks are applied
- in reverse to the index.
-</p>
-<div class="para"><p>This means that <tt>git reset -p</tt> is the opposite of <tt>git add -p</tt> (see
-<a href="git-add.html">git-add(1)</a>).</p></div>
+</dl></div>
</dd>
+</dl></div>
+<div class="para"><p>If you want to undo a commit other than the latest on a branch,
+<a href="git-revert.html">git-revert(1)</a> is your friend.</p></div>
+</div>
+<h2 id="_options">OPTIONS</h2>
+<div class="sectionbody">
+<div class="vlist"><dl>
<dt>
-q
</dt>
@@ -421,134 +440,54 @@ HEAD.</p></div> Be quiet, only report errors.
</p>
</dd>
-<dt>
-<commit>
-</dt>
-<dd>
-<p>
- Commit to make the current HEAD. If not given defaults to HEAD.
-</p>
-</dd>
</dl></div>
</div>
-<h2 id="_discussion">DISCUSSION</h2>
+<h2 id="_examples">EXAMPLES</h2>
<div class="sectionbody">
-<div class="para"><p>The tables below show what happens when running:</p></div>
+<div class="vlist"><dl>
+<dt>
+Undo add
+</dt>
+<dd>
<div class="listingblock">
<div class="content">
-<pre><tt>git reset --option target</tt></pre>
-</div></div>
-<div class="para"><p>to reset the HEAD to another commit (<tt>target</tt>) with the different
-reset options depending on the state of the files.</p></div>
-<div class="para"><p>In these tables, A, B, C and D are some different states of a
-file. For example, the first line of the first table means that if a
-file is in state A in the working tree, in state B in the index, in
-state C in HEAD and in state D in the target, then "git reset --soft
-target" will put the file in state A in the working tree, in state B
-in the index and in state D in HEAD.</p></div>
-<div class="literalblock">
-<div class="content">
-<pre><tt>working index HEAD target working index HEAD
-----------------------------------------------------
- A B C D --soft A B D
- --mixed A D D
- --hard D D D
- --merge (disallowed)
- --keep (disallowed)</tt></pre>
-</div></div>
-<div class="literalblock">
-<div class="content">
-<pre><tt>working index HEAD target working index HEAD
-----------------------------------------------------
- A B C C --soft A B C
- --mixed A C C
- --hard C C C
- --merge (disallowed)
- --keep A C C</tt></pre>
-</div></div>
-<div class="literalblock">
-<div class="content">
-<pre><tt>working index HEAD target working index HEAD
-----------------------------------------------------
- B B C D --soft B B D
- --mixed B D D
- --hard D D D
- --merge D D D
- --keep (disallowed)</tt></pre>
-</div></div>
-<div class="literalblock">
-<div class="content">
-<pre><tt>working index HEAD target working index HEAD
-----------------------------------------------------
- B B C C --soft B B C
- --mixed B C C
- --hard C C C
- --merge C C C
- --keep B C C</tt></pre>
-</div></div>
-<div class="literalblock">
-<div class="content">
-<pre><tt>working index HEAD target working index HEAD
-----------------------------------------------------
- B C C D --soft B C D
- --mixed B D D
- --hard D D D
- --merge (disallowed)
- --keep (disallowed)</tt></pre>
-</div></div>
-<div class="literalblock">
-<div class="content">
-<pre><tt>working index HEAD target working index HEAD
-----------------------------------------------------
- B C C C --soft B C C
- --mixed B C C
- --hard C C C
- --merge B C C
- --keep B C C</tt></pre>
-</div></div>
-<div class="para"><p>"reset --merge" is meant to be used when resetting out of a conflicted
-merge. Any mergy operation guarantees that the work tree file that is
-involved in the merge does not have local change wrt the index before
-it starts, and that it writes the result out to the work tree. So if
-we see some difference between the index and the target and also
-between the index and the work tree, then it means that we are not
-resetting out from a state that a mergy operation left after failing
-with a conflict. That is why we disallow --merge option in this case.</p></div>
-<div class="para"><p>"reset --keep" is meant to be used when removing some of the last
-commits in the current branch while keeping changes in the working
-tree. If there could be conflicts between the changes in the commit we
-want to remove and the changes in the working tree we want to keep,
-the reset is disallowed. That's why it is disallowed if there are both
-changes between the working tree and HEAD, and between HEAD and the
-target. To be safe, it is also disallowed when there are unmerged
-entries.</p></div>
-<div class="para"><p>The following tables show what happens when there are unmerged
-entries:</p></div>
-<div class="literalblock">
-<div class="content">
-<pre><tt>working index HEAD target working index HEAD
-----------------------------------------------------
- X U A B --soft (disallowed)
- --mixed X B B
- --hard B B B
- --merge B B B
- --keep (disallowed)</tt></pre>
-</div></div>
-<div class="literalblock">
-<div class="content">
-<pre><tt>working index HEAD target working index HEAD
-----------------------------------------------------
- X U A A --soft (disallowed)
- --mixed X A A
- --hard A A A
- --merge A A A
- --keep (disallowed)</tt></pre>
+<pre><tt>$ edit <b>(1)</b>
+$ git add frotz.c filfre.c
+$ mailx <b>(2)</b>
+$ git reset <b>(3)</b>
+$ git pull git://info.example.com/ nitfol <b>(4)</b></tt></pre>
</div></div>
-<div class="para"><p>X means any state and U means an unmerged index.</p></div>
-</div>
-<h2 id="_examples">Examples</h2>
-<div class="sectionbody">
-<div class="vlist"><dl>
+<div class="colist"><ol>
+<li>
+<p>
+You are happily working on something, and find the changes
+in these files are in good order. You do not want to see them
+when you run "git diff", because you plan to work on other files
+and changes with these files are distracting.
+</p>
+</li>
+<li>
+<p>
+Somebody asks you to pull, and the changes sounds worthy of merging.
+</p>
+</li>
+<li>
+<p>
+However, you already dirtied the index (i.e. your index does
+not match the HEAD commit). But you know the pull you are going
+to make does not affect frotz.c nor filfre.c, so you revert the
+index changes for these two files. Your changes in working tree
+remain there.
+</p>
+</li>
+<li>
+<p>
+Then you can pull and merge, leaving frotz.c and filfre.c
+changes still in the working tree.
+</p>
+</li>
+</ol></div>
+</dd>
<dt>
Undo a commit and redo
</dt>
@@ -584,27 +523,6 @@ edit the message further, you can give -C option instead. </ol></div>
</dd>
<dt>
-Undo commits permanently
-</dt>
-<dd>
-<div class="listingblock">
-<div class="content">
-<pre><tt>$ git commit ...
-$ git reset --hard HEAD~3 <b>(1)</b></tt></pre>
-</div></div>
-<div class="colist"><ol>
-<li>
-<p>
-The last three commits (HEAD, HEAD^, and HEAD~2) were bad
-and you do not want to ever see them again. Do <strong>not</strong> do this if
-you have already given these commits to somebody else. (See the
-"RECOVERING FROM UPSTREAM REBASE" section in <a href="git-rebase.html">git-rebase(1)</a> for
-the implications of doing so.)
-</p>
-</li>
-</ol></div>
-</dd>
-<dt>
Undo a commit, making it a topic branch
</dt>
<dd>
@@ -636,44 +554,22 @@ Switch to "topic/wip" branch and keep working. </ol></div>
</dd>
<dt>
-Undo add
+Undo commits permanently
</dt>
<dd>
<div class="listingblock">
<div class="content">
-<pre><tt>$ edit <b>(1)</b>
-$ git add frotz.c filfre.c
-$ mailx <b>(2)</b>
-$ git reset <b>(3)</b>
-$ git pull git://info.example.com/ nitfol <b>(4)</b></tt></pre>
+<pre><tt>$ git commit ...
+$ git reset --hard HEAD~3 <b>(1)</b></tt></pre>
</div></div>
<div class="colist"><ol>
<li>
<p>
-You are happily working on something, and find the changes
-in these files are in good order. You do not want to see them
-when you run "git diff", because you plan to work on other files
-and changes with these files are distracting.
-</p>
-</li>
-<li>
-<p>
-Somebody asks you to pull, and the changes sounds worthy of merging.
-</p>
-</li>
-<li>
-<p>
-However, you already dirtied the index (i.e. your index does
-not match the HEAD commit). But you know the pull you are going
-to make does not affect frotz.c nor filfre.c, so you revert the
-index changes for these two files. Your changes in working tree
-remain there.
-</p>
-</li>
-<li>
-<p>
-Then you can pull and merge, leaving frotz.c and filfre.c
-changes still in the working tree.
+The last three commits (HEAD, HEAD^, and HEAD~2) were bad
+and you do not want to ever see them again. Do <strong>not</strong> do this if
+you have already given these commits to somebody else. (See the
+"RECOVERING FROM UPSTREAM REBASE" section in <a href="git-rebase.html">git-rebase(1)</a> for
+the implications of doing so.)
</p>
</li>
</ol></div>
@@ -876,6 +772,121 @@ But you can use "reset --keep" to remove the unwanted commit after </dd>
</dl></div>
</div>
+<h2 id="_discussion">DISCUSSION</h2>
+<div class="sectionbody">
+<div class="para"><p>The tables below show what happens when running:</p></div>
+<div class="listingblock">
+<div class="content">
+<pre><tt>git reset --option target</tt></pre>
+</div></div>
+<div class="para"><p>to reset the HEAD to another commit (<tt>target</tt>) with the different
+reset options depending on the state of the files.</p></div>
+<div class="para"><p>In these tables, A, B, C and D are some different states of a
+file. For example, the first line of the first table means that if a
+file is in state A in the working tree, in state B in the index, in
+state C in HEAD and in state D in the target, then "git reset --soft
+target" will put the file in state A in the working tree, in state B
+in the index and in state D in HEAD.</p></div>
+<div class="literalblock">
+<div class="content">
+<pre><tt>working index HEAD target working index HEAD
+----------------------------------------------------
+ A B C D --soft A B D
+ --mixed A D D
+ --hard D D D
+ --merge (disallowed)
+ --keep (disallowed)</tt></pre>
+</div></div>
+<div class="literalblock">
+<div class="content">
+<pre><tt>working index HEAD target working index HEAD
+----------------------------------------------------
+ A B C C --soft A B C
+ --mixed A C C
+ --hard C C C
+ --merge (disallowed)
+ --keep A C C</tt></pre>
+</div></div>
+<div class="literalblock">
+<div class="content">
+<pre><tt>working index HEAD target working index HEAD
+----------------------------------------------------
+ B B C D --soft B B D
+ --mixed B D D
+ --hard D D D
+ --merge D D D
+ --keep (disallowed)</tt></pre>
+</div></div>
+<div class="literalblock">
+<div class="content">
+<pre><tt>working index HEAD target working index HEAD
+----------------------------------------------------
+ B B C C --soft B B C
+ --mixed B C C
+ --hard C C C
+ --merge C C C
+ --keep B C C</tt></pre>
+</div></div>
+<div class="literalblock">
+<div class="content">
+<pre><tt>working index HEAD target working index HEAD
+----------------------------------------------------
+ B C C D --soft B C D
+ --mixed B D D
+ --hard D D D
+ --merge (disallowed)
+ --keep (disallowed)</tt></pre>
+</div></div>
+<div class="literalblock">
+<div class="content">
+<pre><tt>working index HEAD target working index HEAD
+----------------------------------------------------
+ B C C C --soft B C C
+ --mixed B C C
+ --hard C C C
+ --merge B C C
+ --keep B C C</tt></pre>
+</div></div>
+<div class="para"><p>"reset --merge" is meant to be used when resetting out of a conflicted
+merge. Any mergy operation guarantees that the work tree file that is
+involved in the merge does not have local change wrt the index before
+it starts, and that it writes the result out to the work tree. So if
+we see some difference between the index and the target and also
+between the index and the work tree, then it means that we are not
+resetting out from a state that a mergy operation left after failing
+with a conflict. That is why we disallow --merge option in this case.</p></div>
+<div class="para"><p>"reset --keep" is meant to be used when removing some of the last
+commits in the current branch while keeping changes in the working
+tree. If there could be conflicts between the changes in the commit we
+want to remove and the changes in the working tree we want to keep,
+the reset is disallowed. That's why it is disallowed if there are both
+changes between the working tree and HEAD, and between HEAD and the
+target. To be safe, it is also disallowed when there are unmerged
+entries.</p></div>
+<div class="para"><p>The following tables show what happens when there are unmerged
+entries:</p></div>
+<div class="literalblock">
+<div class="content">
+<pre><tt>working index HEAD target working index HEAD
+----------------------------------------------------
+ X U A B --soft (disallowed)
+ --mixed X B B
+ --hard B B B
+ --merge B B B
+ --keep (disallowed)</tt></pre>
+</div></div>
+<div class="literalblock">
+<div class="content">
+<pre><tt>working index HEAD target working index HEAD
+----------------------------------------------------
+ X U A A --soft (disallowed)
+ --mixed X A A
+ --hard A A A
+ --merge A A A
+ --keep (disallowed)</tt></pre>
+</div></div>
+<div class="para"><p>X means any state and U means an unmerged index.</p></div>
+</div>
<h2 id="_author">Author</h2>
<div class="sectionbody">
<div class="para"><p>Written by Junio C Hamano <gitster@pobox.com> and Linus Torvalds <torvalds@osdl.org></p></div>
@@ -890,7 +901,7 @@ But you can use "reset --keep" to remove the unwanted commit after </div>
<div id="footer">
<div id="footer-text">
-Last updated 2010-07-21 21:55:34 UTC
+Last updated 2010-08-13 02:46:20 UTC
</div>
</div>
</body>
|