doc/source/en/TortoiseGit/git_doc/git-checkout.xml

   1 <?xml version="1.0" encoding="UTF-8"?>\r
   2 <!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd">\r
   3 \r
   4 <article lang="en" id="git-checkout(1)">\r
   5 <articleinfo>\r
   6     <title>git-checkout(1)</title>\r
   7 <indexterm>\r
   8 <primary>git-checkout(1)</primary>\r
   9 </indexterm>\r
  10 </articleinfo>\r
  11 <simplesect id="_name">\r
  12 <title>NAME</title>\r
  13 <simpara>git-checkout - Checkout a branch or paths to the working tree</simpara>\r
  14 </simplesect>\r
  15 <simplesect id="_synopsis">\r
  16 <title>SYNOPSIS</title>\r
  17 <blockquote>\r
  18 <literallayout><emphasis>git checkout</emphasis> [-q] [-f] [-m] [&lt;branch&gt;]\r
  19 <emphasis>git checkout</emphasis> [-q] [-f] [-m] [--detach] [&lt;commit&gt;]\r
  20 <emphasis>git checkout</emphasis> [-q] [-f] [-m] [[-b|-B|--orphan] &lt;new_branch&gt;] [&lt;start_point&gt;]\r
  21 <emphasis>git checkout</emphasis> [-f|--ours|--theirs|-m|--conflict=&lt;style&gt;] [&lt;tree-ish&gt;] [--] &lt;paths&gt;&#8230;\r
  22 <emphasis>git checkout</emphasis> [-p|--patch] [&lt;tree-ish&gt;] [--] [&lt;paths&gt;&#8230;]</literallayout>\r
  23 </blockquote>\r
  24 </simplesect>\r
  25 <simplesect id="_description">\r
  26 <title>DESCRIPTION</title>\r
  27 <simpara>Updates files in the working tree to match the version in the index\r
  28 or the specified tree.  If no paths are given, <emphasis>git checkout</emphasis> will\r
  29 also update <emphasis>HEAD</emphasis> to set the specified branch as the current\r
  30 branch.</simpara>\r
  31 <variablelist>\r
  32 <varlistentry>\r
  33 <term>\r
  34 <emphasis>git checkout</emphasis> [&lt;branch&gt;]\r
  35 </term>\r
  36 <term>\r
  37 <emphasis>git checkout</emphasis> -b|-B &lt;new_branch&gt; [&lt;start point&gt;]\r
  38 </term>\r
  39 <term>\r
  40 <emphasis>git checkout</emphasis> [--detach] [&lt;commit&gt;]\r
  41 </term>\r
  42 <listitem>\r
  43 <simpara>\r
  44         This form switches branches by updating the index, working\r
  45         tree, and HEAD to reflect the specified branch or commit.\r
  46 </simpara>\r
  47 <simpara>If <emphasis>-b</emphasis> is given, a new branch is created as if <xref linkend="git-branch(1)" />\r
  48 were called and then checked out; in this case you can\r
  49 use the <emphasis>--track</emphasis> or <emphasis>--no-track</emphasis> options, which will be passed to\r
  50 <emphasis>git branch</emphasis>.  As a convenience, <emphasis>--track</emphasis> without <emphasis>-b</emphasis> implies branch\r
  51 creation; see the description of <emphasis>--track</emphasis> below.</simpara>\r
  52 <simpara>If <emphasis>-B</emphasis> is given, &lt;new_branch&gt; is created if it doesn't exist; otherwise, it\r
  53 is reset. This is the transactional equivalent of</simpara>\r
  54 <screen>$ git branch -f &lt;branch&gt; [&lt;start point&gt;]\r
  55 $ git checkout &lt;branch&gt;</screen>\r
  56 <simpara>that is to say, the branch is not reset/created unless "git checkout" is\r
  57 successful.</simpara>\r
  58 </listitem>\r
  59 </varlistentry>\r
  60 <varlistentry>\r
  61 <term>\r
  62 <emphasis>git checkout</emphasis> [-p|--patch] [&lt;tree-ish&gt;] [--] &lt;pathspec&gt;&#8230;\r
  63 </term>\r
  64 <listitem>\r
  65 <simpara>\r
  66         When &lt;paths&gt; or <emphasis>--patch</emphasis> are given, <emphasis>git checkout</emphasis> does <emphasis role="strong">not</emphasis>\r
  67         switch branches.  It updates the named paths in the working tree\r
  68         from the index file or from a named &lt;tree-ish&gt; (most often a\r
  69         commit).  In this case, the <emphasis>-b</emphasis> and <emphasis>--track</emphasis> options are\r
  70         meaningless and giving either of them results in an error.  The\r
  71         &lt;tree-ish&gt; argument can be used to specify a specific tree-ish\r
  72         (i.e.  commit, tag or tree) to update the index for the given\r
  73         paths before updating the working tree.\r
  74 </simpara>\r
  75 <simpara>The index may contain unmerged entries because of a previous failed merge.\r
  76 By default, if you try to check out such an entry from the index, the\r
  77 checkout operation will fail and nothing will be checked out.\r
  78 Using <emphasis>-f</emphasis> will ignore these unmerged entries.  The contents from a\r
  79 specific side of the merge can be checked out of the index by\r
  80 using <emphasis>--ours</emphasis> or <emphasis>--theirs</emphasis>.  With <emphasis>-m</emphasis>, changes made to the working tree\r
  81 file can be discarded to re-create the original conflicted merge result.</simpara>\r
  82 </listitem>\r
  83 </varlistentry>\r
  84 </variablelist>\r
  85 </simplesect>\r
  86 <simplesect id="_options">\r
  87 <title>OPTIONS</title>\r
  88 <variablelist>\r
  89 <varlistentry>\r
  90 <term>\r
  91 -q\r
  92 </term>\r
  93 <term>\r
  94 --quiet\r
  95 </term>\r
  96 <listitem>\r
  97 <simpara>\r
  98         Quiet, suppress feedback messages.\r
  99 </simpara>\r
 100 </listitem>\r
 101 </varlistentry>\r
 102 <varlistentry>\r
 103 <term>\r
 104 -f\r
 105 </term>\r
 106 <term>\r
 107 --force\r
 108 </term>\r
 109 <listitem>\r
 110 <simpara>\r
 111         When switching branches, proceed even if the index or the\r
 112         working tree differs from HEAD.  This is used to throw away\r
 113         local changes.\r
 114 </simpara>\r
 115 <simpara>When checking out paths from the index, do not fail upon unmerged\r
 116 entries; instead, unmerged entries are ignored.</simpara>\r
 117 </listitem>\r
 118 </varlistentry>\r
 119 <varlistentry>\r
 120 <term>\r
 121 --ours\r
 122 </term>\r
 123 <term>\r
 124 --theirs\r
 125 </term>\r
 126 <listitem>\r
 127 <simpara>\r
 128         When checking out paths from the index, check out stage #2\r
 129         (<emphasis>ours</emphasis>) or #3 (<emphasis>theirs</emphasis>) for unmerged paths.\r
 130 </simpara>\r
 131 </listitem>\r
 132 </varlistentry>\r
 133 <varlistentry>\r
 134 <term>\r
 135 -b\r
 136 </term>\r
 137 <listitem>\r
 138 <simpara>\r
 139         Create a new branch named &lt;new_branch&gt; and start it at\r
 140         &lt;start_point&gt;; see <xref linkend="git-branch(1)" /> for details.\r
 141 </simpara>\r
 142 </listitem>\r
 143 </varlistentry>\r
 144 <varlistentry>\r
 145 <term>\r
 146 -B\r
 147 </term>\r
 148 <listitem>\r
 149 <simpara>\r
 150         Creates the branch &lt;new_branch&gt; and start it at &lt;start_point&gt;;\r
 151         if it already exists, then reset it to &lt;start_point&gt;. This is\r
 152         equivalent to running "git branch" with "-f"; see\r
 153         <xref linkend="git-branch(1)" /> for details.\r
 154 </simpara>\r
 155 </listitem>\r
 156 </varlistentry>\r
 157 <varlistentry>\r
 158 <term>\r
 159 -t\r
 160 </term>\r
 161 <term>\r
 162 --track\r
 163 </term>\r
 164 <listitem>\r
 165 <simpara>\r
 166         When creating a new branch, set up "upstream" configuration. See\r
 167         "--track" in <xref linkend="git-branch(1)" /> for details.\r
 168 </simpara>\r
 169 <simpara>If no <emphasis>-b</emphasis> option is given, the name of the new branch will be\r
 170 derived from the remote-tracking branch.  If "remotes/" or "refs/remotes/"\r
 171 is prefixed it is stripped away, and then the part up to the\r
 172 next slash (which would be the nickname of the remote) is removed.\r
 173 This would tell us to use "hack" as the local branch when branching\r
 174 off of "origin/hack" (or "remotes/origin/hack", or even\r
 175 "refs/remotes/origin/hack").  If the given name has no slash, or the above\r
 176 guessing results in an empty name, the guessing is aborted.  You can\r
 177 explicitly give a name with <emphasis>-b</emphasis> in such a case.</simpara>\r
 178 </listitem>\r
 179 </varlistentry>\r
 180 <varlistentry>\r
 181 <term>\r
 182 --no-track\r
 183 </term>\r
 184 <listitem>\r
 185 <simpara>\r
 186         Do not set up "upstream" configuration, even if the\r
 187         branch.autosetupmerge configuration variable is true.\r
 188 </simpara>\r
 189 </listitem>\r
 190 </varlistentry>\r
 191 <varlistentry>\r
 192 <term>\r
 193 -l\r
 194 </term>\r
 195 <listitem>\r
 196 <simpara>\r
 197         Create the new branch's reflog; see <xref linkend="git-branch(1)" /> for\r
 198         details.\r
 199 </simpara>\r
 200 </listitem>\r
 201 </varlistentry>\r
 202 <varlistentry>\r
 203 <term>\r
 204 --detach\r
 205 </term>\r
 206 <listitem>\r
 207 <simpara>\r
 208         Rather than checking out a branch to work on it, check out a\r
 209         commit for inspection and discardable experiments.\r
 210         This is the default behavior of "git checkout &lt;commit&gt;" when\r
 211         &lt;commit&gt; is not a branch name.  See the "DETACHED HEAD" section\r
 212         below for details.\r
 213 </simpara>\r
 214 </listitem>\r
 215 </varlistentry>\r
 216 <varlistentry>\r
 217 <term>\r
 218 --orphan\r
 219 </term>\r
 220 <listitem>\r
 221 <simpara>\r
 222         Create a new <emphasis>orphan</emphasis> branch, named &lt;new_branch&gt;, started from\r
 223         &lt;start_point&gt; and switch to it.  The first commit made on this\r
 224         new branch will have no parents and it will be the root of a new\r
 225         history totally disconnected from all the other branches and\r
 226         commits.\r
 227 </simpara>\r
 228 <simpara>The index and the working tree are adjusted as if you had previously run\r
 229 "git checkout &lt;start_point&gt;".  This allows you to start a new history\r
 230 that records a set of paths similar to &lt;start_point&gt; by easily running\r
 231 "git commit -a" to make the root commit.</simpara>\r
 232 <simpara>This can be useful when you want to publish the tree from a commit\r
 233 without exposing its full history. You might want to do this to publish\r
 234 an open source branch of a project whose current tree is "clean", but\r
 235 whose full history contains proprietary or otherwise encumbered bits of\r
 236 code.</simpara>\r
 237 <simpara>If you want to start a disconnected history that records a set of paths\r
 238 that is totally different from the one of &lt;start_point&gt;, then you should\r
 239 clear the index and the working tree right after creating the orphan\r
 240 branch by running "git rm -rf ." from the top level of the working tree.\r
 241 Afterwards you will be ready to prepare your new files, repopulating the\r
 242 working tree, by copying them from elsewhere, extracting a tarball, etc.</simpara>\r
 243 </listitem>\r
 244 </varlistentry>\r
 245 <varlistentry>\r
 246 <term>\r
 247 -m\r
 248 </term>\r
 249 <term>\r
 250 --merge\r
 251 </term>\r
 252 <listitem>\r
 253 <simpara>\r
 254         When switching branches,\r
 255         if you have local modifications to one or more files that\r
 256         are different between the current branch and the branch to\r
 257         which you are switching, the command refuses to switch\r
 258         branches in order to preserve your modifications in context.\r
 259         However, with this option, a three-way merge between the current\r
 260         branch, your working tree contents, and the new branch\r
 261         is done, and you will be on the new branch.\r
 262 </simpara>\r
 263 <simpara>When a merge conflict happens, the index entries for conflicting\r
 264 paths are left unmerged, and you need to resolve the conflicts\r
 265 and mark the resolved paths with <emphasis>git add</emphasis> (or <emphasis>git rm</emphasis> if the merge\r
 266 should result in deletion of the path).</simpara>\r
 267 <simpara>When checking out paths from the index, this option lets you recreate\r
 268 the conflicted merge in the specified paths.</simpara>\r
 269 </listitem>\r
 270 </varlistentry>\r
 271 <varlistentry>\r
 272 <term>\r
 273 --conflict=&lt;style&gt;\r
 274 </term>\r
 275 <listitem>\r
 276 <simpara>\r
 277         The same as --merge option above, but changes the way the\r
 278         conflicting hunks are presented, overriding the\r
 279         merge.conflictstyle configuration variable.  Possible values are\r
 280         "merge" (default) and "diff3" (in addition to what is shown by\r
 281         "merge" style, shows the original contents).\r
 282 </simpara>\r
 283 </listitem>\r
 284 </varlistentry>\r
 285 <varlistentry>\r
 286 <term>\r
 287 -p\r
 288 </term>\r
 289 <term>\r
 290 --patch\r
 291 </term>\r
 292 <listitem>\r
 293 <simpara>\r
 294         Interactively select hunks in the difference between the\r
 295         &lt;tree-ish&gt; (or the index, if unspecified) and the working\r
 296         tree.  The chosen hunks are then applied in reverse to the\r
 297         working tree (and if a &lt;tree-ish&gt; was specified, the index).\r
 298 </simpara>\r
 299 <simpara>This means that you can use <emphasis>git checkout -p</emphasis> to selectively discard\r
 300 edits from your current working tree. See the Interactive Mode\r
 301 section of <xref linkend="git-add(1)" /> to learn how to operate the <emphasis>--patch</emphasis> mode.</simpara>\r
 302 </listitem>\r
 303 </varlistentry>\r
 304 <varlistentry>\r
 305 <term>\r
 306 &lt;branch&gt;\r
 307 </term>\r
 308 <listitem>\r
 309 <simpara>\r
 310         Branch to checkout; if it refers to a branch (i.e., a name that,\r
 311         when prepended with "refs/heads/", is a valid ref), then that\r
 312         branch is checked out. Otherwise, if it refers to a valid\r
 313         commit, your HEAD becomes "detached" and you are no longer on\r
 314         any branch (see below for details).\r
 315 </simpara>\r
 316 <simpara>As a special case, the <emphasis>"@{-N}"</emphasis> syntax for the N-th last branch\r
 317 checks out the branch (instead of detaching).  You may also specify\r
 318 <emphasis>-</emphasis> which is synonymous with <emphasis>"@{-1}"</emphasis>.</simpara>\r
 319 <simpara>As a further special case, you may use <emphasis>"A...B"</emphasis> as a shortcut for the\r
 320 merge base of <emphasis>A</emphasis> and <emphasis>B</emphasis> if there is exactly one merge base. You can\r
 321 leave out at most one of <emphasis>A</emphasis> and <emphasis>B</emphasis>, in which case it defaults to <emphasis>HEAD</emphasis>.</simpara>\r
 322 </listitem>\r
 323 </varlistentry>\r
 324 <varlistentry>\r
 325 <term>\r
 326 &lt;new_branch&gt;\r
 327 </term>\r
 328 <listitem>\r
 329 <simpara>\r
 330         Name for the new branch.\r
 331 </simpara>\r
 332 </listitem>\r
 333 </varlistentry>\r
 334 <varlistentry>\r
 335 <term>\r
 336 &lt;start_point&gt;\r
 337 </term>\r
 338 <listitem>\r
 339 <simpara>\r
 340         The name of a commit at which to start the new branch; see\r
 341         <xref linkend="git-branch(1)" /> for details. Defaults to HEAD.\r
 342 </simpara>\r
 343 </listitem>\r
 344 </varlistentry>\r
 345 <varlistentry>\r
 346 <term>\r
 347 &lt;tree-ish&gt;\r
 348 </term>\r
 349 <listitem>\r
 350 <simpara>\r
 351         Tree to checkout from (when paths are given). If not specified,\r
 352         the index will be used.\r
 353 </simpara>\r
 354 </listitem>\r
 355 </varlistentry>\r
 356 </variablelist>\r
 357 </simplesect>\r
 358 <simplesect id="_detached_head">\r
 359 <title>DETACHED HEAD</title>\r
 360 <simpara>HEAD normally refers to a named branch (e.g. <emphasis>master</emphasis>). Meanwhile, each\r
 361 branch refers to a specific commit. Let's look at a repo with three\r
 362 commits, one of them tagged, and with branch <emphasis>master</emphasis> checked out:</simpara>\r
 363 <screen>           HEAD (refers to branch 'master')\r
 364             |\r
 365             v\r
 366 a---b---c  branch 'master' (refers to commit 'c')\r
 367     ^\r
 368     |\r
 369   tag 'v2.0' (refers to commit 'b')</screen>\r
 370 <simpara>When a commit is created in this state, the branch is updated to refer to\r
 371 the new commit. Specifically, <emphasis>git commit</emphasis> creates a new commit <emphasis>d</emphasis>, whose\r
 372 parent is commit <emphasis>c</emphasis>, and then updates branch <emphasis>master</emphasis> to refer to new\r
 373 commit <emphasis>d</emphasis>. HEAD still refers to branch <emphasis>master</emphasis> and so indirectly now refers\r
 374 to commit <emphasis>d</emphasis>:</simpara>\r
 375 <screen>$ edit; git add; git commit\r
 376 \r
 377                HEAD (refers to branch 'master')\r
 378                 |\r
 379                 v\r
 380 a---b---c---d  branch 'master' (refers to commit 'd')\r
 381     ^\r
 382     |\r
 383   tag 'v2.0' (refers to commit 'b')</screen>\r
 384 <simpara>It is sometimes useful to be able to checkout a commit that is not at\r
 385 the tip of any named branch, or even to create a new commit that is not\r
 386 referenced by a named branch. Let's look at what happens when we\r
 387 checkout commit <emphasis>b</emphasis> (here we show two ways this may be done):</simpara>\r
 388 <screen>$ git checkout v2.0  # or\r
 389 $ git checkout master^^\r
 390 \r
 391    HEAD (refers to commit 'b')\r
 392     |\r
 393     v\r
 394 a---b---c---d  branch 'master' (refers to commit 'd')\r
 395     ^\r
 396     |\r
 397   tag 'v2.0' (refers to commit 'b')</screen>\r
 398 <simpara>Notice that regardless of which checkout command we use, HEAD now refers\r
 399 directly to commit <emphasis>b</emphasis>. This is known as being in detached HEAD state.\r
 400 It means simply that HEAD refers to a specific commit, as opposed to\r
 401 referring to a named branch. Let's see what happens when we create a commit:</simpara>\r
 402 <screen>$ edit; git add; git commit\r
 403 \r
 404      HEAD (refers to commit 'e')\r
 405       |\r
 406       v\r
 407       e\r
 408      /\r
 409 a---b---c---d  branch 'master' (refers to commit 'd')\r
 410     ^\r
 411     |\r
 412   tag 'v2.0' (refers to commit 'b')</screen>\r
 413 <simpara>There is now a new commit <emphasis>e</emphasis>, but it is referenced only by HEAD. We can\r
 414 of course add yet another commit in this state:</simpara>\r
 415 <screen>$ edit; git add; git commit\r
 416 \r
 417          HEAD (refers to commit 'f')\r
 418           |\r
 419           v\r
 420       e---f\r
 421      /\r
 422 a---b---c---d  branch 'master' (refers to commit 'd')\r
 423     ^\r
 424     |\r
 425   tag 'v2.0' (refers to commit 'b')</screen>\r
 426 <simpara>In fact, we can perform all the normal git operations. But, let's look\r
 427 at what happens when we then checkout master:</simpara>\r
 428 <screen>$ git checkout master\r
 429 \r
 430                HEAD (refers to branch 'master')\r
 431       e---f     |\r
 432      /          v\r
 433 a---b---c---d  branch 'master' (refers to commit 'd')\r
 434     ^\r
 435     |\r
 436   tag 'v2.0' (refers to commit 'b')</screen>\r
 437 <simpara>It is important to realize that at this point nothing refers to commit\r
 438 <emphasis>f</emphasis>. Eventually commit <emphasis>f</emphasis> (and by extension commit <emphasis>e</emphasis>) will be deleted\r
 439 by the routine git garbage collection process, unless we create a reference\r
 440 before that happens. If we have not yet moved away from commit <emphasis>f</emphasis>,\r
 441 any of these will create a reference to it:</simpara>\r
 442 <screen>$ git checkout -b foo   <co id="CO1-1"/>\r
 443 $ git branch foo        <co id="CO1-2"/>\r
 444 $ git tag foo           <co id="CO1-3"/></screen>\r
 445 <calloutlist>\r
 446 <callout arearefs="CO1-1">\r
 447 <para>\r
 448 creates a new branch <emphasis>foo</emphasis>, which refers to commit <emphasis>f</emphasis>, and then\r
 449 updates HEAD to refer to branch <emphasis>foo</emphasis>. In other words, we'll no longer\r
 450 be in detached HEAD state after this command.\r
 451 </para>\r
 452 </callout>\r
 453 <callout arearefs="CO1-2">\r
 454 <para>\r
 455 similarly creates a new branch <emphasis>foo</emphasis>, which refers to commit <emphasis>f</emphasis>,\r
 456 but leaves HEAD detached.\r
 457 </para>\r
 458 </callout>\r
 459 <callout arearefs="CO1-3">\r
 460 <para>\r
 461 creates a new tag <emphasis>foo</emphasis>, which refers to commit <emphasis>f</emphasis>,\r
 462 leaving HEAD detached.\r
 463 </para>\r
 464 </callout>\r
 465 </calloutlist>\r
 466 <simpara>If we have moved away from commit <emphasis>f</emphasis>, then we must first recover its object\r
 467 name (typically by using git reflog), and then we can create a reference to\r
 468 it. For example, to see the last two commits to which HEAD referred, we\r
 469 can use either of these commands:</simpara>\r
 470 <screen>$ git reflog -2 HEAD # or\r
 471 $ git log -g -2 HEAD</screen>\r
 472 </simplesect>\r
 473 <simplesect id="_examples">\r
 474 <title>EXAMPLES</title>\r
 475 <orderedlist numeration="arabic">\r
 476 <listitem>\r
 477 <simpara>\r
 478 The following sequence checks out the <emphasis>master</emphasis> branch, reverts\r
 479 the <emphasis>Makefile</emphasis> to two revisions back, deletes hello.c by\r
 480 mistake, and gets it back from the index.\r
 481 </simpara>\r
 482 <screen>$ git checkout master             <co id="CO2-1"/>\r
 483 $ git checkout master~2 Makefile  <co id="CO2-2"/>\r
 484 $ rm -f hello.c\r
 485 $ git checkout hello.c            <co id="CO2-3"/></screen>\r
 486 <calloutlist>\r
 487 <callout arearefs="CO2-1">\r
 488 <para>\r
 489 switch branch\r
 490 </para>\r
 491 </callout>\r
 492 <callout arearefs="CO2-2">\r
 493 <para>\r
 494 take a file out of another commit\r
 495 </para>\r
 496 </callout>\r
 497 <callout arearefs="CO2-3">\r
 498 <para>\r
 499 restore hello.c from the index\r
 500 </para>\r
 501 <simpara>If you have an unfortunate branch that is named <emphasis>hello.c</emphasis>, this\r
 502 step would be confused as an instruction to switch to that branch.\r
 503 You should instead write:</simpara>\r
 504 <screen>$ git checkout -- hello.c</screen>\r
 505 </callout>\r
 506 </calloutlist>\r
 507 </listitem>\r
 508 <listitem>\r
 509 <simpara>\r
 510 After working in the wrong branch, switching to the correct\r
 511 branch would be done using:\r
 512 </simpara>\r
 513 <screen>$ git checkout mytopic</screen>\r
 514 <simpara>However, your "wrong" branch and correct "mytopic" branch may\r
 515 differ in files that you have modified locally, in which case\r
 516 the above checkout would fail like this:</simpara>\r
 517 <screen>$ git checkout mytopic\r
 518 error: You have local changes to 'frotz'; not switching branches.</screen>\r
 519 <simpara>You can give the <emphasis>-m</emphasis> flag to the command, which would try a\r
 520 three-way merge:</simpara>\r
 521 <screen>$ git checkout -m mytopic\r
 522 Auto-merging frotz</screen>\r
 523 <simpara>After this three-way merge, the local modifications are <emphasis>not</emphasis>\r
 524 registered in your index file, so <emphasis>git diff</emphasis> would show you what\r
 525 changes you made since the tip of the new branch.</simpara>\r
 526 </listitem>\r
 527 <listitem>\r
 528 <simpara>\r
 529 When a merge conflict happens during switching branches with\r
 530 the <emphasis>-m</emphasis> option, you would see something like this:\r
 531 </simpara>\r
 532 <screen>$ git checkout -m mytopic\r
 533 Auto-merging frotz\r
 534 ERROR: Merge conflict in frotz\r
 535 fatal: merge program failed</screen>\r
 536 <simpara>At this point, <emphasis>git diff</emphasis> shows the changes cleanly merged as in\r
 537 the previous example, as well as the changes in the conflicted\r
 538 files.  Edit and resolve the conflict and mark it resolved with\r
 539 <emphasis>git add</emphasis> as usual:</simpara>\r
 540 <screen>$ edit frotz\r
 541 $ git add frotz</screen>\r
 542 </listitem>\r
 543 </orderedlist>\r
 544 </simplesect>\r
 545 <simplesect id="_git">\r
 546 <title>GIT</title>\r
 547 <simpara>Part of the <xref linkend="git(1)" /> suite</simpara>\r
 548 </simplesect>\r
 549 </article>\r