</div>\r
<h2>SYNOPSIS</h2>\r
<div class="sectionbody">\r
-<p><em>git-checkout</em> [-f] [-b <new_branch>] [<branch>] [<paths>…]</p>\r
+<p><em>git-checkout</em> [-f] [-b <new_branch>] [-m] [<branch>] [<paths>…]</p>\r
</div>\r
<h2>DESCRIPTION</h2>\r
<div class="sectionbody">\r
</p>\r
</dd>\r
<dt>\r
+-m\r
+</dt>\r
+<dd>\r
+<p>\r
+ If you have local modifications to a file that is\r
+ different between the current branch and the branch you\r
+ are switching to, the command refuses to switch\r
+ branches, to preserve your modifications in context.\r
+ With this option, a three-way merge between the current\r
+ branch, your working tree contents, and the new branch\r
+ is done, and you will be on the new branch.\r
+</p>\r
+<p>When a merge conflict happens, the index entries for conflicting\r
+paths are left unmerged, and you need to resolve the conflicts\r
+and mark the resolved paths with <tt>git update-index</tt>.</p>\r
+</dd>\r
+<dt>\r
<new_branch>\r
</dt>\r
<dd>\r
</dd>\r
</dl>\r
</div>\r
-<h2>EXAMPLE</h2>\r
+<h2>EXAMPLES</h2>\r
<div class="sectionbody">\r
-<p>The following sequence checks out the <tt>master</tt> branch, reverts\r
+<ol>\r
+<li>\r
+<p>\r
+The following sequence checks out the <tt>master</tt> branch, reverts\r
the <tt>Makefile</tt> to two revisions back, deletes hello.c by\r
-mistake, and gets it back from the index.</p>\r
+mistake, and gets it back from the index.\r
+</p>\r
<div class="listingblock">\r
<div class="content">\r
<pre><tt>$ git checkout master <b>(1)</b>\r
<div class="content">\r
<pre><tt>$ git checkout -- hello.c</tt></pre>\r
</div></div>\r
+</li>\r
+<li>\r
+<p>\r
+After working in a wrong branch, switching to the correct\r
+branch you would want to is done with:\r
+</p>\r
+<div class="listingblock">\r
+<div class="content">\r
+<pre><tt>$ git checkout mytopic</tt></pre>\r
+</div></div>\r
+<p>However, your "wrong" branch and correct "mytopic" branch may\r
+differ in files that you have locally modified, in which case,\r
+the above checkout would fail like this:</p>\r
+<div class="listingblock">\r
+<div class="content">\r
+<pre><tt>$ git checkout mytopic\r
+fatal: Entry 'frotz' not uptodate. Cannot merge.</tt></pre>\r
+</div></div>\r
+<p>You can give the <tt>-m</tt> flag to the command, which would try a\r
+three-way merge:</p>\r
+<div class="listingblock">\r
+<div class="content">\r
+<pre><tt>$ git checkout -m mytopic\r
+Auto-merging frotz</tt></pre>\r
+</div></div>\r
+<p>After this three-way merge, the local modifications are _not_\r
+registered in your index file, so <tt>git diff</tt> would show you what\r
+changes you made since the tip of the new branch.</p>\r
+</li>\r
+<li>\r
+<p>\r
+When a merge conflict happens during switching branches with\r
+the <tt>-m</tt> option, you would see something like this:\r
+</p>\r
+<div class="listingblock">\r
+<div class="content">\r
+<pre><tt>$ git checkout -m mytopic\r
+Auto-merging frotz\r
+merge: warning: conflicts during merge\r
+ERROR: Merge conflict in frotz\r
+fatal: merge program failed</tt></pre>\r
+</div></div>\r
+<p>At this point, <tt>git diff</tt> shows the changes cleanly merged as in\r
+the previous example, as well as the changes in the conflicted\r
+files. Edit and resolve the conflict and mark it resolved with\r
+<tt>git update-index</tt> as usual:</p>\r
+<div class="listingblock">\r
+<div class="content">\r
+<pre><tt>$ edit frotz\r
+$ git update-index frotz</tt></pre>\r
+</div></div>\r
+</li>\r
+</ol>\r
</div>\r
<h2>Author</h2>\r
<div class="sectionbody">\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 27-Dec-2005 00:15:51 PDT\r
+Last updated 13-Jan-2006 19:58:25 PDT\r
</div>\r
</div>\r
</body>\r
SYNOPSIS
--------
-'git-checkout' [-f] [-b <new_branch>] [<branch>] [<paths>...]
+'git-checkout' [-f] [-b <new_branch>] [
-m] [<branch>] [<paths>...]
DESCRIPTION
-----------
-b::
Create a new branch and start it at <branch>.
+-m::
+ If you have local modifications to a file that is
+ different between the current branch and the branch you
+ are switching to, the command refuses to switch
+ branches, to preserve your modifications in context.
+ With this option, a three-way merge between the current
+ branch, your working tree contents, and the new branch
+ is done, and you will be on the new branch.
++
+When a merge conflict happens, the index entries for conflicting
+paths are left unmerged, and you need to resolve the conflicts
+and mark the resolved paths with `git update-index`.
+
<new_branch>::
Name for the new branch.
commit. Defaults to HEAD.
-EXAMPLE
--------
+EXAMPLES
+--------
-The following sequence checks out the `master` branch, reverts
+. The following sequence checks out the `master` branch, reverts
the `Makefile` to two revisions back, deletes hello.c by
mistake, and gets it back from the index.
-
++
------------
$ git checkout master <1>
$ git checkout master~2 Makefile <2>
<2> take out a file out of other commit
<3> or "git checkout -- hello.c", as in the next example.
------------
-
++
If you have an unfortunate branch that is named `hello.c`, the
last step above would be confused as an instruction to switch to
that branch. You should instead write:
-
++
------------
$ git checkout -- hello.c
------------
+. After working in a wrong branch, switching to the correct
+branch you would want to is done with:
++
+------------
+$ git checkout mytopic
+------------
++
+However, your "wrong" branch and correct "mytopic" branch may
+differ in files that you have locally modified, in which case,
+the above checkout would fail like this:
++
+------------
+$ git checkout mytopic
+fatal: Entry 'frotz' not uptodate. Cannot merge.
+------------
++
+You can give the `-m` flag to the command, which would try a
+three-way merge:
++
+------------
+$ git checkout -m mytopic
+Auto-merging frotz
+------------
++
+After this three-way merge, the local modifications are _not_
+registered in your index file, so `git diff` would show you what
+changes you made since the tip of the new branch.
+
+. When a merge conflict happens during switching branches with
+the `-m` option, you would see something like this:
++
+------------
+$ git checkout -m mytopic
+Auto-merging frotz
+merge: warning: conflicts during merge
+ERROR: Merge conflict in frotz
+fatal: merge program failed
+------------
++
+At this point, `git diff` shows the changes cleanly merged as in
+the previous example, as well as the changes in the conflicted
+files. Edit and resolve the conflict and mark it resolved with
+`git update-index` as usual:
++
+------------
+$ edit frotz
+$ git update-index frotz
+------------
+
Author
------
</dt>\r
<dd>\r
<p>\r
- Update all paths in the index file.\r
+ Update all paths in the index file. This flag notices\r
+ files that have been modified and deleted, but new files\r
+ you have not told about git are not affected.\r
</p>\r
</dd>\r
<dt>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 06-Jan-2006 17:12:13 PDT\r
+Last updated 13-Jan-2006 19:58:26 PDT\r
</div>\r
</div>\r
</body>\r
OPTIONS
-------
-a|--all::
- Update all paths in the index file.
+ Update all paths in the index file. This flag notices
+ files that have been modified and deleted, but new files
+ you have not told about git are not affected.
-c or -C <commit>::
Take existing commit object, and reuse the log message
<ul>\r
<li>\r
<p>\r
-For backward compatibility, <tt>tag</tt> is almost ignored;\r
- it just makes the following parameter <tag> to mean a\r
- refspec <tt>refs/tags/<tag>:refs/tags/<tag></tt>.\r
+<tt>tag <tag></tt> means the same as <tt>refs/tags/<tag>:refs/tags/<tag></tt>;\r
+ used with pull or fetch, it requests fetching everything up to\r
+ the given tag.\r
</p>\r
</li>\r
<li>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 11-Jan-2006 03:35:13 PDT\r
+Last updated 13-Jan-2006 19:58:27 PDT\r
</div>\r
</div>\r
</body>\r
<ul>\r
<li>\r
<p>\r
-For backward compatibility, <tt>tag</tt> is almost ignored;\r
- it just makes the following parameter <tag> to mean a\r
- refspec <tt>refs/tags/<tag>:refs/tags/<tag></tt>.\r
+<tt>tag <tag></tt> means the same as <tt>refs/tags/<tag>:refs/tags/<tag></tt>;\r
+ used with pull or fetch, it requests fetching everything up to\r
+ the given tag.\r
</p>\r
</li>\r
<li>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 11-Jan-2006 03:35:14 PDT\r
+Last updated 13-Jan-2006 19:58:28 PDT\r
</div>\r
</div>\r
</body>\r
<ul>\r
<li>\r
<p>\r
-For backward compatibility, <tt>tag</tt> is almost ignored;\r
- it just makes the following parameter <tag> to mean a\r
- refspec <tt>refs/tags/<tag>:refs/tags/<tag></tt>.\r
+<tt>tag <tag></tt> means the same as <tt>refs/tags/<tag>:refs/tags/<tag></tt>;\r
+ used with pull or fetch, it requests fetching everything up to\r
+ the given tag.\r
</p>\r
</li>\r
<li>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 27-Dec-2005 00:16:30 PDT\r
+Last updated 13-Jan-2006 19:58:29 PDT\r
</div>\r
</div>\r
</body>\r
and resets the tip of the branch to that commit.</tt></pre>\r
</div></div>\r
</dd>\r
+<dt>\r
+Interrupted workflow\r
+</dt>\r
+<dd>\r
+<p>You can get interrupted by an ungent fix request while you are\r
+still in the middle of a large change. The files in your\r
+working tree are not in any shape to be committed yet, but you\r
+need to get to the other branch for a quick bugfix.</p>\r
+<div class="listingblock">\r
+<div class="content">\r
+<pre><tt>$ git checkout feature ;# you were working in "feature" branch and\r
+$ work work work ;# got interrupted\r
+$ git commit -a -m 'snapshot WIP' <b>(1)</b>\r
+$ git checkout master\r
+$ fix fix fix\r
+$ git commit ;# commit with real log\r
+$ git checkout feature\r
+$ git reset --soft HEAD^ ;# go back to WIP state <b>(2)</b>\r
+$ git reset <b>(3)</b>\r
+\r
+<b>(1)</b> This commit will get blown away so a throw-away log message is OK.\r
+<b>(2)</b> This removes the 'WIP' commit from the commit history, and makes\r
+ your working tree in the state just before you made that snapshot.\r
+<b>(3)</b> After <b>(2)</b>, the index file still has all the WIP changes you\r
+ committed in <b>(1)</b>. This sets it to the last commit you were\r
+ basing the WIP changes on.</tt></pre>\r
+</div></div>\r
+</dd>\r
</dl>\r
</div>\r
<h2>Author</h2>\r
</div>\r
<div id="footer">\r
<div id="footer-text">\r
-Last updated 27-Dec-2005 00:16:36 PDT\r
+Last updated 13-Jan-2006 19:58:30 PDT\r
</div>\r
</div>\r
</body>\r
and resets the tip of the branch to that commit.
------------
+Interrupted workflow::
++
+You can get interrupted by an ungent fix request while you are
+still in the middle of a large change. The files in your
+working tree are not in any shape to be committed yet, but you
+need to get to the other branch for a quick bugfix.
++
+------------
+$ git checkout feature ;# you were working in "feature" branch and
+$ work work work ;# got interrupted
+$ git commit -a -m 'snapshot WIP' <1>
+$ git checkout master
+$ fix fix fix
+$ git commit ;# commit with real log
+$ git checkout feature
+$ git reset --soft HEAD^ ;# go back to WIP state <2>
+$ git reset <3>
+
+<1> This commit will get blown away so a throw-away log message is OK.
+<2> This removes the 'WIP' commit from the commit history, and makes
+ your working tree in the state just before you made that snapshot.
+<3> After <2>, the index file still has all the WIP changes you
+ committed in <1>. This sets it to the last commit you were
+ basing the WIP changes on.
+------------
+
Author
------
Written by Junio C Hamano <junkio@cox.net> and Linus Torvalds <torvalds@osdl.org>
GIT
---
Part of the gitlink:git[7] suite
-
+
Some short-cut notations are also supported.
+
-* For backward compatibility, `tag` is almost ignored;
- it just makes the following parameter <tag> to mean a
- refspec `refs/tags/<tag>:refs/tags/<tag>`.
+* `tag <tag>` means the same as `refs/tags/<tag>:refs/tags/<tag>`;
+ used with pull or fetch, it requests fetching everything up to
+ the given tag.
* A parameter <ref> without a colon is equivalent to
<ref>: when pulling/fetching, and <ref>`:`<ref> when
pushing. That is, do not store it locally if
projects / git.git / commitdiff