doc/source/en/TortoiseGit/git_doc/git-pull.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-pull(1)">\r
   5 <articleinfo>\r
   6     <title>git-pull(1)</title>\r
   7 <indexterm>\r
   8 <primary>git-pull(1)</primary>\r
   9 </indexterm>\r
  10 </articleinfo>\r
  11 <simplesect id="_name">\r
  12 <title>NAME</title>\r
  13 <simpara>git-pull - Fetch from and merge with another repository or a local branch</simpara>\r
  14 </simplesect>\r
  15 <simplesect id="_synopsis">\r
  16 <title>SYNOPSIS</title>\r
  17 <blockquote>\r
  18 <literallayout><emphasis>git pull</emphasis> [options] [&lt;repository&gt; [&lt;refspec&gt;&#8230;]]</literallayout>\r
  19 </blockquote>\r
  20 </simplesect>\r
  21 <simplesect id="_description">\r
  22 <title>DESCRIPTION</title>\r
  23 <simpara>Incorporates changes from a remote repository into the current\r
  24 branch.  In its default mode, <emphasis>git pull</emphasis> is shorthand for\r
  25 <emphasis>git fetch</emphasis> followed by <emphasis>git merge FETCH_HEAD</emphasis>.</simpara>\r
  26 <simpara>More precisely, <emphasis>git pull</emphasis> runs <emphasis>git fetch</emphasis> with the given\r
  27 parameters and calls <emphasis>git merge</emphasis> to merge the retrieved branch\r
  28 heads into the current branch.\r
  29 With <emphasis>--rebase</emphasis>, it runs <emphasis>git rebase</emphasis> instead of <emphasis>git merge</emphasis>.</simpara>\r
  30 <simpara>&lt;repository&gt; should be the name of a remote repository as\r
  31 passed to <xref linkend="git-fetch(1)" />.  &lt;refspec&gt; can name an\r
  32 arbitrary remote ref (for example, the name of a tag) or even\r
  33 a collection of refs with corresponding remote-tracking branches\r
  34 (e.g., refs/heads/&#42;:refs/remotes/origin/&#42;),\r
  35 but usually it is the name of a branch in the remote repository.</simpara>\r
  36 <simpara>Default values for &lt;repository&gt; and &lt;branch&gt; are read from the\r
  37 "remote" and "merge" configuration for the current branch\r
  38 as set by <xref linkend="git-branch(1)" /> <emphasis>--track</emphasis>.</simpara>\r
  39 <simpara>Assume the following history exists and the current branch is\r
  40 "<emphasis>master</emphasis>":</simpara>\r
  41 <screen>          A---B---C master on origin\r
  42          /\r
  43     D---E---F---G master</screen>\r
  44 <simpara>Then "<emphasis>git pull</emphasis>" will fetch and replay the changes from the remote\r
  45 <emphasis>master</emphasis> branch since it diverged from the local <emphasis>master</emphasis> (i.e., <emphasis>E</emphasis>)\r
  46 until its current commit (<emphasis>C</emphasis>) on top of <emphasis>master</emphasis> and record the\r
  47 result in a new commit along with the names of the two parent commits\r
  48 and a log message from the user describing the changes.</simpara>\r
  49 <screen>          A---B---C remotes/origin/master\r
  50          /         \\r
  51     D---E---F---G---H master</screen>\r
  52 <simpara>See <xref linkend="git-merge(1)" /> for details, including how conflicts\r
  53 are presented and handled.</simpara>\r
  54 <simpara>In git 1.7.0 or later, to cancel a conflicting merge, use\r
  55 <emphasis>git reset --merge</emphasis>.  <emphasis role="strong">Warning</emphasis>: In older versions of git, running <emphasis>git pull</emphasis>\r
  56 with uncommitted changes is discouraged: while possible, it leaves you\r
  57 in a state that may be hard to back out of in the case of a conflict.</simpara>\r
  58 <simpara>If any of the remote changes overlap with local uncommitted changes,\r
  59 the merge will be automatically cancelled and the work tree untouched.\r
  60 It is generally best to get any local changes in working order before\r
  61 pulling or stash them away with <xref linkend="git-stash(1)" />.</simpara>\r
  62 </simplesect>\r
  63 <simplesect id="_options">\r
  64 <title>OPTIONS</title>\r
  65 <simpara>Options meant for <emphasis>git pull</emphasis> itself and the underlying <emphasis>git merge</emphasis>\r
  66 must be given before the options meant for <emphasis>git fetch</emphasis>.</simpara>\r
  67 <variablelist>\r
  68 <varlistentry>\r
  69 <term>\r
  70 -q\r
  71 </term>\r
  72 <term>\r
  73 --quiet\r
  74 </term>\r
  75 <listitem>\r
  76 <simpara>\r
  77         This is passed to both underlying git-fetch to squelch reporting of\r
  78         during transfer, and underlying git-merge to squelch output during\r
  79         merging.\r
  80 </simpara>\r
  81 </listitem>\r
  82 </varlistentry>\r
  83 <varlistentry>\r
  84 <term>\r
  85 -v\r
  86 </term>\r
  87 <term>\r
  88 --verbose\r
  89 </term>\r
  90 <listitem>\r
  91 <simpara>\r
  92         Pass --verbose to git-fetch and git-merge.\r
  93 </simpara>\r
  94 </listitem>\r
  95 </varlistentry>\r
  96 <varlistentry>\r
  97 <term>\r
  98 --[no-]recurse-submodules[=yes|on-demand|no]\r
  99 </term>\r
 100 <listitem>\r
 101 <simpara>\r
 102         This option controls if new commits of all populated submodules should\r
 103         be fetched too (see <xref linkend="git-config(1)" /> and <xref linkend="gitmodules(5)" />).\r
 104         That might be necessary to get the data needed for merging submodule\r
 105         commits, a feature git learned in 1.7.3. Notice that the result of a\r
 106         merge will not be checked out in the submodule, "git submodule update"\r
 107         has to be called afterwards to bring the work tree up to date with the\r
 108         merge result.\r
 109 </simpara>\r
 110 </listitem>\r
 111 </varlistentry>\r
 112 </variablelist>\r
 113 <section id="_options_related_to_merging">\r
 114 <title>Options related to merging</title>\r
 115 <variablelist>\r
 116 <varlistentry>\r
 117 <term>\r
 118 --commit\r
 119 </term>\r
 120 <term>\r
 121 --no-commit\r
 122 </term>\r
 123 <listitem>\r
 124 <simpara>\r
 125         Perform the merge and commit the result. This option can\r
 126         be used to override --no-commit.\r
 127 </simpara>\r
 128 <simpara>With --no-commit perform the merge but pretend the merge\r
 129 failed and do not autocommit, to give the user a chance to\r
 130 inspect and further tweak the merge result before committing.</simpara>\r
 131 </listitem>\r
 132 </varlistentry>\r
 133 <varlistentry>\r
 134 <term>\r
 135 --edit\r
 136 </term>\r
 137 <term>\r
 138 --no-edit\r
 139 </term>\r
 140 <listitem>\r
 141 <simpara>\r
 142         Invoke an editor before committing successful mechanical merge to\r
 143         further edit the auto-generated merge message, so that the user\r
 144         can explain and justify the merge. The <emphasis>--no-edit</emphasis> option can be\r
 145         used to accept the auto-generated message (this is generally\r
 146         discouraged). The <emphasis>--edit</emphasis> option is still useful if you are\r
 147         giving a draft message with the <emphasis>-m</emphasis> option from the command line\r
 148         and want to edit it in the editor.\r
 149 </simpara>\r
 150 <simpara>Older scripts may depend on the historical behaviour of not allowing the\r
 151 user to edit the merge log message. They will see an editor opened when\r
 152 they run <emphasis>git merge</emphasis>. To make it easier to adjust such scripts to the\r
 153 updated behaviour, the environment variable <emphasis>GIT_MERGE_AUTOEDIT</emphasis> can be\r
 154 set to <emphasis>no</emphasis> at the beginning of them.</simpara>\r
 155 </listitem>\r
 156 </varlistentry>\r
 157 <varlistentry>\r
 158 <term>\r
 159 --ff\r
 160 </term>\r
 161 <listitem>\r
 162 <simpara>\r
 163         When the merge resolves as a fast-forward, only update the branch\r
 164         pointer, without creating a merge commit.  This is the default\r
 165         behavior.\r
 166 </simpara>\r
 167 </listitem>\r
 168 </varlistentry>\r
 169 <varlistentry>\r
 170 <term>\r
 171 --no-ff\r
 172 </term>\r
 173 <listitem>\r
 174 <simpara>\r
 175         Create a merge commit even when the merge resolves as a\r
 176         fast-forward.\r
 177 </simpara>\r
 178 </listitem>\r
 179 </varlistentry>\r
 180 <varlistentry>\r
 181 <term>\r
 182 --ff-only\r
 183 </term>\r
 184 <listitem>\r
 185 <simpara>\r
 186         Refuse to merge and exit with a non-zero status unless the\r
 187         current <emphasis>HEAD</emphasis> is already up-to-date or the merge can be\r
 188         resolved as a fast-forward.\r
 189 </simpara>\r
 190 </listitem>\r
 191 </varlistentry>\r
 192 <varlistentry>\r
 193 <term>\r
 194 --log[=&lt;n&gt;]\r
 195 </term>\r
 196 <term>\r
 197 --no-log\r
 198 </term>\r
 199 <listitem>\r
 200 <simpara>\r
 201         In addition to branch names, populate the log message with\r
 202         one-line descriptions from at most &lt;n&gt; actual commits that are being\r
 203         merged. See also <xref linkend="git-fmt-merge-msg(1)" />.\r
 204 </simpara>\r
 205 <simpara>With --no-log do not list one-line descriptions from the\r
 206 actual commits being merged.</simpara>\r
 207 </listitem>\r
 208 </varlistentry>\r
 209 <varlistentry>\r
 210 <term>\r
 211 --stat\r
 212 </term>\r
 213 <term>\r
 214 -n\r
 215 </term>\r
 216 <term>\r
 217 --no-stat\r
 218 </term>\r
 219 <listitem>\r
 220 <simpara>\r
 221         Show a diffstat at the end of the merge. The diffstat is also\r
 222         controlled by the configuration option merge.stat.\r
 223 </simpara>\r
 224 <simpara>With -n or --no-stat do not show a diffstat at the end of the\r
 225 merge.</simpara>\r
 226 </listitem>\r
 227 </varlistentry>\r
 228 <varlistentry>\r
 229 <term>\r
 230 --squash\r
 231 </term>\r
 232 <term>\r
 233 --no-squash\r
 234 </term>\r
 235 <listitem>\r
 236 <simpara>\r
 237         Produce the working tree and index state as if a real\r
 238         merge happened (except for the merge information),\r
 239         but do not actually make a commit or\r
 240         move the <emphasis>HEAD</emphasis>, nor record <emphasis>$GIT_DIR/MERGE_HEAD</emphasis> to\r
 241         cause the next <emphasis>git commit</emphasis> command to create a merge\r
 242         commit.  This allows you to create a single commit on\r
 243         top of the current branch whose effect is the same as\r
 244         merging another branch (or more in case of an octopus).\r
 245 </simpara>\r
 246 <simpara>With --no-squash perform the merge and commit the result. This\r
 247 option can be used to override --squash.</simpara>\r
 248 </listitem>\r
 249 </varlistentry>\r
 250 <varlistentry>\r
 251 <term>\r
 252 -s &lt;strategy&gt;\r
 253 </term>\r
 254 <term>\r
 255 --strategy=&lt;strategy&gt;\r
 256 </term>\r
 257 <listitem>\r
 258 <simpara>\r
 259         Use the given merge strategy; can be supplied more than\r
 260         once to specify them in the order they should be tried.\r
 261         If there is no <emphasis>-s</emphasis> option, a built-in list of strategies\r
 262         is used instead (<emphasis>git merge-recursive</emphasis> when merging a single\r
 263         head, <emphasis>git merge-octopus</emphasis> otherwise).\r
 264 </simpara>\r
 265 </listitem>\r
 266 </varlistentry>\r
 267 <varlistentry>\r
 268 <term>\r
 269 -X &lt;option&gt;\r
 270 </term>\r
 271 <term>\r
 272 --strategy-option=&lt;option&gt;\r
 273 </term>\r
 274 <listitem>\r
 275 <simpara>\r
 276         Pass merge strategy specific option through to the merge\r
 277         strategy.\r
 278 </simpara>\r
 279 </listitem>\r
 280 </varlistentry>\r
 281 <varlistentry>\r
 282 <term>\r
 283 --summary\r
 284 </term>\r
 285 <term>\r
 286 --no-summary\r
 287 </term>\r
 288 <listitem>\r
 289 <simpara>\r
 290         Synonyms to --stat and --no-stat; these are deprecated and will be\r
 291         removed in the future.\r
 292 </simpara>\r
 293 </listitem>\r
 294 </varlistentry>\r
 295 <varlistentry>\r
 296 <term>\r
 297 -q\r
 298 </term>\r
 299 <term>\r
 300 --quiet\r
 301 </term>\r
 302 <listitem>\r
 303 <simpara>\r
 304         Operate quietly. Implies --no-progress.\r
 305 </simpara>\r
 306 </listitem>\r
 307 </varlistentry>\r
 308 <varlistentry>\r
 309 <term>\r
 310 -v\r
 311 </term>\r
 312 <term>\r
 313 --verbose\r
 314 </term>\r
 315 <listitem>\r
 316 <simpara>\r
 317         Be verbose.\r
 318 </simpara>\r
 319 </listitem>\r
 320 </varlistentry>\r
 321 <varlistentry>\r
 322 <term>\r
 323 --progress\r
 324 </term>\r
 325 <term>\r
 326 --no-progress\r
 327 </term>\r
 328 <listitem>\r
 329 <simpara>\r
 330         Turn progress on/off explicitly. If neither is specified,\r
 331         progress is shown if standard error is connected to a terminal.\r
 332         Note that not all merge strategies may support progress\r
 333         reporting.\r
 334 </simpara>\r
 335 </listitem>\r
 336 </varlistentry>\r
 337 </variablelist>\r
 338 <variablelist>\r
 339 <varlistentry>\r
 340 <term>\r
 341 --rebase\r
 342 </term>\r
 343 <listitem>\r
 344 <simpara>\r
 345         Rebase the current branch on top of the upstream branch after\r
 346         fetching.  If there is a remote-tracking branch corresponding to\r
 347         the upstream branch and the upstream branch was rebased since last\r
 348         fetched, the rebase uses that information to avoid rebasing\r
 349         non-local changes.\r
 350 </simpara>\r
 351 <simpara>See <emphasis>pull.rebase</emphasis>, <emphasis>branch.&lt;name&gt;.rebase</emphasis> and <emphasis>branch.autosetuprebase</emphasis> in\r
 352 <xref linkend="git-config(1)" /> if you want to make <emphasis>git pull</emphasis> always use\r
 353 <emphasis>--rebase</emphasis> instead of merging.</simpara>\r
 354 <note><simpara>This is a potentially <emphasis>dangerous</emphasis> mode of operation.\r
 355 It rewrites history, which does not bode well when you\r
 356 published that history already.  Do <emphasis role="strong">not</emphasis> use this option\r
 357 unless you have read <xref linkend="git-rebase(1)" /> carefully.</simpara></note>\r
 358 </listitem>\r
 359 </varlistentry>\r
 360 <varlistentry>\r
 361 <term>\r
 362 --no-rebase\r
 363 </term>\r
 364 <listitem>\r
 365 <simpara>\r
 366         Override earlier --rebase.\r
 367 </simpara>\r
 368 </listitem>\r
 369 </varlistentry>\r
 370 </variablelist>\r
 371 </section>\r
 372 <section id="_options_related_to_fetching">\r
 373 <title>Options related to fetching</title>\r
 374 <variablelist>\r
 375 <varlistentry>\r
 376 <term>\r
 377 --all\r
 378 </term>\r
 379 <listitem>\r
 380 <simpara>\r
 381         Fetch all remotes.\r
 382 </simpara>\r
 383 </listitem>\r
 384 </varlistentry>\r
 385 <varlistentry>\r
 386 <term>\r
 387 -a\r
 388 </term>\r
 389 <term>\r
 390 --append\r
 391 </term>\r
 392 <listitem>\r
 393 <simpara>\r
 394         Append ref names and object names of fetched refs to the\r
 395         existing contents of <emphasis>.git/FETCH_HEAD</emphasis>.  Without this\r
 396         option old data in <emphasis>.git/FETCH_HEAD</emphasis> will be overwritten.\r
 397 </simpara>\r
 398 </listitem>\r
 399 </varlistentry>\r
 400 <varlistentry>\r
 401 <term>\r
 402 --depth=&lt;depth&gt;\r
 403 </term>\r
 404 <listitem>\r
 405 <simpara>\r
 406         Deepen the history of a <emphasis>shallow</emphasis> repository created by\r
 407         <emphasis>git clone</emphasis> with <emphasis>--depth=&lt;depth&gt;</emphasis> option (see <xref linkend="git-clone(1)" />)\r
 408         by the specified number of commits.\r
 409 </simpara>\r
 410 </listitem>\r
 411 </varlistentry>\r
 412 <varlistentry>\r
 413 <term>\r
 414 -f\r
 415 </term>\r
 416 <term>\r
 417 --force\r
 418 </term>\r
 419 <listitem>\r
 420 <simpara>\r
 421         When <emphasis>git fetch</emphasis> is used with <emphasis>&lt;rbranch&gt;:&lt;lbranch&gt;</emphasis>\r
 422         refspec, it refuses to update the local branch\r
 423         <emphasis>&lt;lbranch&gt;</emphasis> unless the remote branch <emphasis>&lt;rbranch&gt;</emphasis> it\r
 424         fetches is a descendant of <emphasis>&lt;lbranch&gt;</emphasis>.  This option\r
 425         overrides that check.\r
 426 </simpara>\r
 427 </listitem>\r
 428 </varlistentry>\r
 429 <varlistentry>\r
 430 <term>\r
 431 -k\r
 432 </term>\r
 433 <term>\r
 434 --keep\r
 435 </term>\r
 436 <listitem>\r
 437 <simpara>\r
 438         Keep downloaded pack.\r
 439 </simpara>\r
 440 </listitem>\r
 441 </varlistentry>\r
 442 <varlistentry>\r
 443 <term>\r
 444 --no-tags\r
 445 </term>\r
 446 <listitem>\r
 447 <simpara>\r
 448         By default, tags that point at objects that are downloaded\r
 449         from the remote repository are fetched and stored locally.\r
 450         This option disables this automatic tag following. The default\r
 451         behavior for a remote may be specified with the remote.&lt;name&gt;.tagopt\r
 452         setting. See <xref linkend="git-config(1)" />.\r
 453 </simpara>\r
 454 </listitem>\r
 455 </varlistentry>\r
 456 <varlistentry>\r
 457 <term>\r
 458 -u\r
 459 </term>\r
 460 <term>\r
 461 --update-head-ok\r
 462 </term>\r
 463 <listitem>\r
 464 <simpara>\r
 465         By default <emphasis>git fetch</emphasis> refuses to update the head which\r
 466         corresponds to the current branch.  This flag disables the\r
 467         check.  This is purely for the internal use for <emphasis>git pull</emphasis>\r
 468         to communicate with <emphasis>git fetch</emphasis>, and unless you are\r
 469         implementing your own Porcelain you are not supposed to\r
 470         use it.\r
 471 </simpara>\r
 472 </listitem>\r
 473 </varlistentry>\r
 474 <varlistentry>\r
 475 <term>\r
 476 --upload-pack &lt;upload-pack&gt;\r
 477 </term>\r
 478 <listitem>\r
 479 <simpara>\r
 480         When given, and the repository to fetch from is handled\r
 481         by <emphasis>git fetch-pack</emphasis>, <emphasis>--exec=&lt;upload-pack&gt;</emphasis> is passed to\r
 482         the command to specify non-default path for the command\r
 483         run on the other end.\r
 484 </simpara>\r
 485 </listitem>\r
 486 </varlistentry>\r
 487 <varlistentry>\r
 488 <term>\r
 489 --progress\r
 490 </term>\r
 491 <listitem>\r
 492 <simpara>\r
 493         Progress status is reported on the standard error stream\r
 494         by default when it is attached to a terminal, unless -q\r
 495         is specified. This flag forces progress status even if the\r
 496         standard error stream is not directed to a terminal.\r
 497 </simpara>\r
 498 </listitem>\r
 499 </varlistentry>\r
 500 <varlistentry>\r
 501 <term>\r
 502 &lt;repository&gt;\r
 503 </term>\r
 504 <listitem>\r
 505 <simpara>\r
 506         The "remote" repository that is the source of a fetch\r
 507         or pull operation.  This parameter can be either a URL\r
 508         (see the section <link linkend="URLS">GIT URLS</link> below) or the name\r
 509         of a remote (see the section <link linkend="REMOTES">REMOTES</link> below).\r
 510 </simpara>\r
 511 </listitem>\r
 512 </varlistentry>\r
 513 <varlistentry>\r
 514 <term>\r
 515 &lt;refspec&gt;\r
 516 </term>\r
 517 <listitem>\r
 518 <simpara>\r
 519         The format of a &lt;refspec&gt; parameter is an optional plus\r
 520         <emphasis>+</emphasis>, followed by the source ref &lt;src&gt;, followed\r
 521         by a colon <emphasis>:</emphasis>, followed by the destination ref &lt;dst&gt;.\r
 522 </simpara>\r
 523 <simpara>The remote ref that matches &lt;src&gt;\r
 524 is fetched, and if &lt;dst&gt; is not empty string, the local\r
 525 ref that matches it is fast-forwarded using &lt;src&gt;.\r
 526 If the optional plus <emphasis>+</emphasis> is used, the local ref\r
 527 is updated even if it does not result in a fast-forward\r
 528 update.</simpara>\r
 529 <note><simpara>If the remote branch from which you want to pull is\r
 530 modified in non-linear ways such as being rewound and\r
 531 rebased frequently, then a pull will attempt a merge with\r
 532 an older version of itself, likely conflict, and fail.\r
 533 It is under these conditions that you would want to use\r
 534 the <emphasis>+</emphasis> sign to indicate non-fast-forward updates will\r
 535 be needed.  There is currently no easy way to determine\r
 536 or declare that a branch will be made available in a\r
 537 repository with this behavior; the pulling user simply\r
 538 must know this is the expected usage pattern for a branch.</simpara></note>\r
 539 <note><simpara>You never do your own development on branches that appear\r
 540 on the right hand side of a &lt;refspec&gt; colon on <emphasis>Pull:</emphasis> lines;\r
 541 they are to be updated by <emphasis>git fetch</emphasis>.  If you intend to do\r
 542 development derived from a remote branch <emphasis>B</emphasis>, have a <emphasis>Pull:</emphasis>\r
 543 line to track it (i.e. <emphasis>Pull: B:remote-B</emphasis>), and have a separate\r
 544 branch <emphasis>my-B</emphasis> to do your development on top of it.  The latter\r
 545 is created by <emphasis>git branch my-B remote-B</emphasis> (or its equivalent <emphasis>git\r
 546 checkout -b my-B remote-B</emphasis>).  Run <emphasis>git fetch</emphasis> to keep track of\r
 547 the progress of the remote side, and when you see something new\r
 548 on the remote branch, merge it into your development branch with\r
 549 <emphasis>git pull . remote-B</emphasis>, while you are on <emphasis>my-B</emphasis> branch.</simpara></note>\r
 550 <note><simpara>There is a difference between listing multiple &lt;refspec&gt;\r
 551 directly on <emphasis>git pull</emphasis> command line and having multiple\r
 552 <emphasis>Pull:</emphasis> &lt;refspec&gt; lines for a &lt;repository&gt; and running\r
 553 <emphasis>git pull</emphasis> command without any explicit &lt;refspec&gt; parameters.\r
 554 &lt;refspec&gt; listed explicitly on the command line are always\r
 555 merged into the current branch after fetching.  In other words,\r
 556 if you list more than one remote refs, you would be making\r
 557 an Octopus.  While <emphasis>git pull</emphasis> run without any explicit &lt;refspec&gt;\r
 558 parameter takes default &lt;refspec&gt;s from <emphasis>Pull:</emphasis> lines, it\r
 559 merges only the first &lt;refspec&gt; found into the current branch,\r
 560 after fetching all the remote refs.  This is because making an\r
 561 Octopus from remote refs is rarely done, while keeping track\r
 562 of multiple remote heads in one-go by fetching more than one\r
 563 is often useful.</simpara></note>\r
 564 <simpara>Some short-cut notations are also supported.</simpara>\r
 565 <itemizedlist>\r
 566 <listitem>\r
 567 <simpara>\r
 568 <emphasis>tag &lt;tag&gt;</emphasis> means the same as <emphasis>refs/tags/&lt;tag&gt;:refs/tags/&lt;tag&gt;</emphasis>;\r
 569   it requests fetching everything up to the given tag.\r
 570 </simpara>\r
 571 </listitem>\r
 572 <listitem>\r
 573 <simpara>\r
 574 A parameter &lt;ref&gt; without a colon is equivalent to\r
 575   &lt;ref&gt;: when pulling/fetching, so it merges &lt;ref&gt; into the current\r
 576   branch without storing the remote branch anywhere locally\r
 577 </simpara>\r
 578 </listitem>\r
 579 </itemizedlist>\r
 580 </listitem>\r
 581 </varlistentry>\r
 582 </variablelist>\r
 583 </section>\r
 584 </simplesect>\r
 585 <simplesect id="_git_urls_anchor_id_urls_xreflabel_urls">\r
 586 <title>GIT URLS<anchor id="URLS" xreflabel="[URLS]"/></title>\r
 587 <simpara>In general, URLs contain information about the transport protocol, the\r
 588 address of the remote server, and the path to the repository.\r
 589 Depending on the transport protocol, some of this information may be\r
 590 absent.</simpara>\r
 591 <simpara>Git natively supports ssh, git, http, https, ftp, ftps, and rsync\r
 592 protocols. The following syntaxes may be used with them:</simpara>\r
 593 <itemizedlist>\r
 594 <listitem>\r
 595 <simpara>\r
 596 ssh://&#91;user@&#93;host.xz&#91;:port&#93;/path/to/repo.git/\r
 597 </simpara>\r
 598 </listitem>\r
 599 <listitem>\r
 600 <simpara>\r
 601 git://host.xz&#91;:port&#93;/path/to/repo.git/\r
 602 </simpara>\r
 603 </listitem>\r
 604 <listitem>\r
 605 <simpara>\r
 606 http&#91;s&#93;://host.xz&#91;:port&#93;/path/to/repo.git/\r
 607 </simpara>\r
 608 </listitem>\r
 609 <listitem>\r
 610 <simpara>\r
 611 ftp&#91;s&#93;://host.xz&#91;:port&#93;/path/to/repo.git/\r
 612 </simpara>\r
 613 </listitem>\r
 614 <listitem>\r
 615 <simpara>\r
 616 rsync://host.xz/path/to/repo.git/\r
 617 </simpara>\r
 618 </listitem>\r
 619 </itemizedlist>\r
 620 <simpara>An alternative scp-like syntax may also be used with the ssh protocol:</simpara>\r
 621 <itemizedlist>\r
 622 <listitem>\r
 623 <simpara>\r
 624 &#91;user@&#93;host.xz:path/to/repo.git/\r
 625 </simpara>\r
 626 </listitem>\r
 627 </itemizedlist>\r
 628 <simpara>The ssh and git protocols additionally support ~username expansion:</simpara>\r
 629 <itemizedlist>\r
 630 <listitem>\r
 631 <simpara>\r
 632 ssh://&#91;user@&#93;host.xz&#91;:port&#93;/~&#91;user&#93;/path/to/repo.git/\r
 633 </simpara>\r
 634 </listitem>\r
 635 <listitem>\r
 636 <simpara>\r
 637 git://host.xz&#91;:port&#93;/~&#91;user&#93;/path/to/repo.git/\r
 638 </simpara>\r
 639 </listitem>\r
 640 <listitem>\r
 641 <simpara>\r
 642 &#91;user@&#93;host.xz:/~&#91;user&#93;/path/to/repo.git/\r
 643 </simpara>\r
 644 </listitem>\r
 645 </itemizedlist>\r
 646 <simpara>For local repositories, also supported by git natively, the following\r
 647 syntaxes may be used:</simpara>\r
 648 <itemizedlist>\r
 649 <listitem>\r
 650 <simpara>\r
 651 /path/to/repo.git/\r
 652 </simpara>\r
 653 </listitem>\r
 654 <listitem>\r
 655 <simpara>\r
 656 <ulink url="file:///path/to/repo.git/">file:///path/to/repo.git/</ulink>\r
 657 </simpara>\r
 658 </listitem>\r
 659 </itemizedlist>\r
 660 <simpara>These two syntaxes are mostly equivalent, except when cloning, when\r
 661 the former implies --local option. See <xref linkend="git-clone(1)" /> for\r
 662 details.</simpara>\r
 663 <simpara>When git doesn't know how to handle a certain transport protocol, it\r
 664 attempts to use the <emphasis>remote-&lt;transport&gt;</emphasis> remote helper, if one\r
 665 exists. To explicitly request a remote helper, the following syntax\r
 666 may be used:</simpara>\r
 667 <itemizedlist>\r
 668 <listitem>\r
 669 <simpara>\r
 670 &lt;transport&gt;::&lt;address&gt;\r
 671 </simpara>\r
 672 </listitem>\r
 673 </itemizedlist>\r
 674 <simpara>where &lt;address&gt; may be a path, a server and path, or an arbitrary\r
 675 URL-like string recognized by the specific remote helper being\r
 676 invoked. See <xref linkend="git-remote-helpers(1)" /> for details.</simpara>\r
 677 <simpara>If there are a large number of similarly-named remote repositories and\r
 678 you want to use a different format for them (such that the URLs you\r
 679 use will be rewritten into URLs that work), you can create a\r
 680 configuration section of the form:</simpara>\r
 681 <screen>        [url "&lt;actual url base&gt;"]\r
 682                 insteadOf = &lt;other url base&gt;</screen>\r
 683 <simpara>For example, with this:</simpara>\r
 684 <screen>        [url "git://git.host.xz/"]\r
 685                 insteadOf = host.xz:/path/to/\r
 686                 insteadOf = work:</screen>\r
 687 <simpara>a URL like "work:repo.git" or like "host.xz:/path/to/repo.git" will be\r
 688 rewritten in any context that takes a URL to be "git://git.host.xz/repo.git".</simpara>\r
 689 <simpara>If you want to rewrite URLs for push only, you can create a\r
 690 configuration section of the form:</simpara>\r
 691 <screen>        [url "&lt;actual url base&gt;"]\r
 692                 pushInsteadOf = &lt;other url base&gt;</screen>\r
 693 <simpara>For example, with this:</simpara>\r
 694 <screen>        [url "ssh://example.org/"]\r
 695                 pushInsteadOf = git://example.org/</screen>\r
 696 <simpara>a URL like "git://example.org/path/to/repo.git" will be rewritten to\r
 697 "ssh://example.org/path/to/repo.git" for pushes, but pulls will still\r
 698 use the original URL.</simpara>\r
 699 </simplesect>\r
 700 <simplesect id="_remotes_anchor_id_remotes_xreflabel_remotes">\r
 701 <title>REMOTES<anchor id="REMOTES" xreflabel="[REMOTES]"/></title>\r
 702 <simpara>The name of one of the following can be used instead\r
 703 of a URL as <emphasis>&lt;repository&gt;</emphasis> argument:</simpara>\r
 704 <itemizedlist>\r
 705 <listitem>\r
 706 <simpara>\r
 707 a remote in the git configuration file: <emphasis>$GIT_DIR/config</emphasis>,\r
 708 </simpara>\r
 709 </listitem>\r
 710 <listitem>\r
 711 <simpara>\r
 712 a file in the <emphasis>$GIT_DIR/remotes</emphasis> directory, or\r
 713 </simpara>\r
 714 </listitem>\r
 715 <listitem>\r
 716 <simpara>\r
 717 a file in the <emphasis>$GIT_DIR/branches</emphasis> directory.\r
 718 </simpara>\r
 719 </listitem>\r
 720 </itemizedlist>\r
 721 <simpara>All of these also allow you to omit the refspec from the command line\r
 722 because they each contain a refspec which git will use by default.</simpara>\r
 723 <section id="_named_remote_in_configuration_file">\r
 724 <title>Named remote in configuration file</title>\r
 725 <simpara>You can choose to provide the name of a remote which you had previously\r
 726 configured using <xref linkend="git-remote(1)" />, <xref linkend="git-config(1)" />\r
 727 or even by a manual edit to the <emphasis>$GIT_DIR/config</emphasis> file.  The URL of\r
 728 this remote will be used to access the repository.  The refspec\r
 729 of this remote will be used by default when you do\r
 730 not provide a refspec on the command line.  The entry in the\r
 731 config file would appear like this:</simpara>\r
 732 <screen>        [remote "&lt;name&gt;"]\r
 733                 url = &lt;url&gt;\r
 734                 pushurl = &lt;pushurl&gt;\r
 735                 push = &lt;refspec&gt;\r
 736                 fetch = &lt;refspec&gt;</screen>\r
 737 <simpara>The <emphasis>&lt;pushurl&gt;</emphasis> is used for pushes only. It is optional and defaults\r
 738 to <emphasis>&lt;url&gt;</emphasis>.</simpara>\r
 739 </section>\r
 740 <section id="_named_file_in_emphasis_git_dir_remotes_emphasis">\r
 741 <title>Named file in <emphasis>$GIT_DIR/remotes</emphasis></title>\r
 742 <simpara>You can choose to provide the name of a\r
 743 file in <emphasis>$GIT_DIR/remotes</emphasis>.  The URL\r
 744 in this file will be used to access the repository.  The refspec\r
 745 in this file will be used as default when you do not\r
 746 provide a refspec on the command line.  This file should have the\r
 747 following format:</simpara>\r
 748 <screen>        URL: one of the above URL format\r
 749         Push: &lt;refspec&gt;\r
 750         Pull: &lt;refspec&gt;</screen>\r
 751 <simpara><emphasis>Push:</emphasis> lines are used by <emphasis>git push</emphasis> and\r
 752 <emphasis>Pull:</emphasis> lines are used by <emphasis>git pull</emphasis> and <emphasis>git fetch</emphasis>.\r
 753 Multiple <emphasis>Push:</emphasis> and <emphasis>Pull:</emphasis> lines may\r
 754 be specified for additional branch mappings.</simpara>\r
 755 </section>\r
 756 <section id="_named_file_in_emphasis_git_dir_branches_emphasis">\r
 757 <title>Named file in <emphasis>$GIT_DIR/branches</emphasis></title>\r
 758 <simpara>You can choose to provide the name of a\r
 759 file in <emphasis>$GIT_DIR/branches</emphasis>.\r
 760 The URL in this file will be used to access the repository.\r
 761 This file should have the following format:</simpara>\r
 762 <screen>        &lt;url&gt;#&lt;head&gt;</screen>\r
 763 <simpara><emphasis>&lt;url&gt;</emphasis> is required; <emphasis>#&lt;head&gt;</emphasis> is optional.</simpara>\r
 764 <simpara>Depending on the operation, git will use one of the following\r
 765 refspecs, if you don't provide one on the command line.\r
 766 <emphasis>&lt;branch&gt;</emphasis> is the name of this file in <emphasis>$GIT_DIR/branches</emphasis> and\r
 767 <emphasis>&lt;head&gt;</emphasis> defaults to <emphasis>master</emphasis>.</simpara>\r
 768 <simpara>git fetch uses:</simpara>\r
 769 <screen>        refs/heads/&lt;head&gt;:refs/heads/&lt;branch&gt;</screen>\r
 770 <simpara>git push uses:</simpara>\r
 771 <screen>        HEAD:refs/heads/&lt;head&gt;</screen>\r
 772 </section>\r
 773 </simplesect>\r
 774 <simplesect id="_merge_strategies">\r
 775 <title>MERGE STRATEGIES</title>\r
 776 <simpara>The merge mechanism (<emphasis>git-merge</emphasis> and <emphasis>git-pull</emphasis> commands) allows the\r
 777 backend <emphasis>merge strategies</emphasis> to be chosen with <emphasis>-s</emphasis> option.  Some strategies\r
 778 can also take their own options, which can be passed by giving <emphasis>-X&lt;option&gt;</emphasis>\r
 779 arguments to <emphasis>git-merge</emphasis> and/or <emphasis>git-pull</emphasis>.</simpara>\r
 780 <variablelist>\r
 781 <varlistentry>\r
 782 <term>\r
 783 resolve\r
 784 </term>\r
 785 <listitem>\r
 786 <simpara>\r
 787         This can only resolve two heads (i.e. the current branch\r
 788         and another branch you pulled from) using a 3-way merge\r
 789         algorithm.  It tries to carefully detect criss-cross\r
 790         merge ambiguities and is considered generally safe and\r
 791         fast.\r
 792 </simpara>\r
 793 </listitem>\r
 794 </varlistentry>\r
 795 <varlistentry>\r
 796 <term>\r
 797 recursive\r
 798 </term>\r
 799 <listitem>\r
 800 <simpara>\r
 801         This can only resolve two heads using a 3-way merge\r
 802         algorithm.  When there is more than one common\r
 803         ancestor that can be used for 3-way merge, it creates a\r
 804         merged tree of the common ancestors and uses that as\r
 805         the reference tree for the 3-way merge.  This has been\r
 806         reported to result in fewer merge conflicts without\r
 807         causing mis-merges by tests done on actual merge commits\r
 808         taken from Linux 2.6 kernel development history.\r
 809         Additionally this can detect and handle merges involving\r
 810         renames.  This is the default merge strategy when\r
 811         pulling or merging one branch.\r
 812 </simpara>\r
 813 <simpara>The <emphasis>recursive</emphasis> strategy can take the following options:</simpara>\r
 814 <variablelist>\r
 815 <varlistentry>\r
 816 <term>\r
 817 ours\r
 818 </term>\r
 819 <listitem>\r
 820 <simpara>\r
 821         This option forces conflicting hunks to be auto-resolved cleanly by\r
 822         favoring <emphasis>our</emphasis> version.  Changes from the other tree that do not\r
 823         conflict with our side are reflected to the merge result.\r
 824 </simpara>\r
 825 <simpara>This should not be confused with the <emphasis>ours</emphasis> merge strategy, which does not\r
 826 even look at what the other tree contains at all.  It discards everything\r
 827 the other tree did, declaring <emphasis>our</emphasis> history contains all that happened in it.</simpara>\r
 828 </listitem>\r
 829 </varlistentry>\r
 830 <varlistentry>\r
 831 <term>\r
 832 theirs\r
 833 </term>\r
 834 <listitem>\r
 835 <simpara>\r
 836         This is opposite of <emphasis>ours</emphasis>.\r
 837 </simpara>\r
 838 </listitem>\r
 839 </varlistentry>\r
 840 <varlistentry>\r
 841 <term>\r
 842 patience\r
 843 </term>\r
 844 <listitem>\r
 845 <simpara>\r
 846         With this option, <emphasis>merge-recursive</emphasis> spends a little extra time\r
 847         to avoid mismerges that sometimes occur due to unimportant\r
 848         matching lines (e.g., braces from distinct functions).  Use\r
 849         this when the branches to be merged have diverged wildly.\r
 850         See also <xref linkend="git-diff(1)" /> <emphasis>--patience</emphasis>.\r
 851 </simpara>\r
 852 </listitem>\r
 853 </varlistentry>\r
 854 <varlistentry>\r
 855 <term>\r
 856 ignore-space-change\r
 857 </term>\r
 858 <term>\r
 859 ignore-all-space\r
 860 </term>\r
 861 <term>\r
 862 ignore-space-at-eol\r
 863 </term>\r
 864 <listitem>\r
 865 <simpara>\r
 866         Treats lines with the indicated type of whitespace change as\r
 867         unchanged for the sake of a three-way merge.  Whitespace\r
 868         changes mixed with other changes to a line are not ignored.\r
 869         See also <xref linkend="git-diff(1)" /> <emphasis>-b</emphasis>, <emphasis>-w</emphasis>, and\r
 870         <emphasis>--ignore-space-at-eol</emphasis>.\r
 871 </simpara>\r
 872 <itemizedlist>\r
 873 <listitem>\r
 874 <simpara>\r
 875 If <emphasis>their</emphasis> version only introduces whitespace changes to a line,\r
 876   <emphasis>our</emphasis> version is used;\r
 877 </simpara>\r
 878 </listitem>\r
 879 <listitem>\r
 880 <simpara>\r
 881 If <emphasis>our</emphasis> version introduces whitespace changes but <emphasis>their</emphasis>\r
 882   version includes a substantial change, <emphasis>their</emphasis> version is used;\r
 883 </simpara>\r
 884 </listitem>\r
 885 <listitem>\r
 886 <simpara>\r
 887 Otherwise, the merge proceeds in the usual way.\r
 888 </simpara>\r
 889 </listitem>\r
 890 </itemizedlist>\r
 891 </listitem>\r
 892 </varlistentry>\r
 893 <varlistentry>\r
 894 <term>\r
 895 renormalize\r
 896 </term>\r
 897 <listitem>\r
 898 <simpara>\r
 899         This runs a virtual check-out and check-in of all three stages\r
 900         of a file when resolving a three-way merge.  This option is\r
 901         meant to be used when merging branches with different clean\r
 902         filters or end-of-line normalization rules.  See "Merging\r
 903         branches with differing checkin/checkout attributes" in\r
 904         <xref linkend="gitattributes(5)" /> for details.\r
 905 </simpara>\r
 906 </listitem>\r
 907 </varlistentry>\r
 908 <varlistentry>\r
 909 <term>\r
 910 no-renormalize\r
 911 </term>\r
 912 <listitem>\r
 913 <simpara>\r
 914         Disables the <emphasis>renormalize</emphasis> option.  This overrides the\r
 915         <emphasis>merge.renormalize</emphasis> configuration variable.\r
 916 </simpara>\r
 917 </listitem>\r
 918 </varlistentry>\r
 919 <varlistentry>\r
 920 <term>\r
 921 rename-threshold=&lt;n&gt;\r
 922 </term>\r
 923 <listitem>\r
 924 <simpara>\r
 925         Controls the similarity threshold used for rename detection.\r
 926         See also <xref linkend="git-diff(1)" /> <emphasis>-M</emphasis>.\r
 927 </simpara>\r
 928 </listitem>\r
 929 </varlistentry>\r
 930 <varlistentry>\r
 931 <term>\r
 932 subtree[=&lt;path&gt;]\r
 933 </term>\r
 934 <listitem>\r
 935 <simpara>\r
 936         This option is a more advanced form of <emphasis>subtree</emphasis> strategy, where\r
 937         the strategy makes a guess on how two trees must be shifted to\r
 938         match with each other when merging.  Instead, the specified path\r
 939         is prefixed (or stripped from the beginning) to make the shape of\r
 940         two trees to match.\r
 941 </simpara>\r
 942 </listitem>\r
 943 </varlistentry>\r
 944 </variablelist>\r
 945 </listitem>\r
 946 </varlistentry>\r
 947 <varlistentry>\r
 948 <term>\r
 949 octopus\r
 950 </term>\r
 951 <listitem>\r
 952 <simpara>\r
 953         This resolves cases with more than two heads, but refuses to do\r
 954         a complex merge that needs manual resolution.  It is\r
 955         primarily meant to be used for bundling topic branch\r
 956         heads together.  This is the default merge strategy when\r
 957         pulling or merging more than one branch.\r
 958 </simpara>\r
 959 </listitem>\r
 960 </varlistentry>\r
 961 <varlistentry>\r
 962 <term>\r
 963 ours\r
 964 </term>\r
 965 <listitem>\r
 966 <simpara>\r
 967         This resolves any number of heads, but the resulting tree of the\r
 968         merge is always that of the current branch head, effectively\r
 969         ignoring all changes from all other branches.  It is meant to\r
 970         be used to supersede old development history of side\r
 971         branches.  Note that this is different from the -Xours option to\r
 972         the <emphasis>recursive</emphasis> merge strategy.\r
 973 </simpara>\r
 974 </listitem>\r
 975 </varlistentry>\r
 976 <varlistentry>\r
 977 <term>\r
 978 subtree\r
 979 </term>\r
 980 <listitem>\r
 981 <simpara>\r
 982         This is a modified recursive strategy. When merging trees A and\r
 983         B, if B corresponds to a subtree of A, B is first adjusted to\r
 984         match the tree structure of A, instead of reading the trees at\r
 985         the same level. This adjustment is also done to the common\r
 986         ancestor tree.\r
 987 </simpara>\r
 988 </listitem>\r
 989 </varlistentry>\r
 990 </variablelist>\r
 991 </simplesect>\r
 992 <simplesect id="_default_behaviour">\r
 993 <title>DEFAULT BEHAVIOUR</title>\r
 994 <simpara>Often people use <emphasis>git pull</emphasis> without giving any parameter.\r
 995 Traditionally, this has been equivalent to saying <emphasis>git pull\r
 996 origin</emphasis>.  However, when configuration <emphasis>branch.&lt;name&gt;.remote</emphasis> is\r
 997 present while on branch <emphasis>&lt;name&gt;</emphasis>, that value is used instead of\r
 998 <emphasis>origin</emphasis>.</simpara>\r
 999 <simpara>In order to determine what URL to use to fetch from, the value\r
1000 of the configuration <emphasis>remote.&lt;origin&gt;.url</emphasis> is consulted\r
1001 and if there is not any such variable, the value on <emphasis>URL: ` line\r
1002 in `$GIT_DIR/remotes/&lt;origin&gt;</emphasis> file is used.</simpara>\r
1003 <simpara>In order to determine what remote branches to fetch (and\r
1004 optionally store in the remote-tracking branches) when the command is\r
1005 run without any refspec parameters on the command line, values\r
1006 of the configuration variable <emphasis>remote.&lt;origin&gt;.fetch</emphasis> are\r
1007 consulted, and if there aren't any, <emphasis>$GIT_DIR/remotes/&lt;origin&gt;</emphasis>\r
1008 file is consulted and its `Pull: ` lines are used.\r
1009 In addition to the refspec formats described in the OPTIONS\r
1010 section, you can have a globbing refspec that looks like this:</simpara>\r
1011 <screen>refs/heads/*:refs/remotes/origin/*</screen>\r
1012 <simpara>A globbing refspec must have a non-empty RHS (i.e. must store\r
1013 what were fetched in remote-tracking branches), and its LHS and RHS\r
1014 must end with <emphasis>/*</emphasis>.  The above specifies that all remote\r
1015 branches are tracked using remote-tracking branches in\r
1016 <emphasis>refs/remotes/origin/</emphasis> hierarchy under the same name.</simpara>\r
1017 <simpara>The rule to determine which remote branch to merge after\r
1018 fetching is a bit involved, in order not to break backward\r
1019 compatibility.</simpara>\r
1020 <simpara>If explicit refspecs were given on the command\r
1021 line of <emphasis>git pull</emphasis>, they are all merged.</simpara>\r
1022 <simpara>When no refspec was given on the command line, then <emphasis>git pull</emphasis>\r
1023 uses the refspec from the configuration or\r
1024 <emphasis>$GIT_DIR/remotes/&lt;origin&gt;</emphasis>.  In such cases, the following\r
1025 rules apply:</simpara>\r
1026 <orderedlist numeration="arabic">\r
1027 <listitem>\r
1028 <simpara>\r
1029 If <emphasis>branch.&lt;name&gt;.merge</emphasis> configuration for the current\r
1030   branch <emphasis>&lt;name&gt;</emphasis> exists, that is the name of the branch at the\r
1031   remote site that is merged.\r
1032 </simpara>\r
1033 </listitem>\r
1034 <listitem>\r
1035 <simpara>\r
1036 If the refspec is a globbing one, nothing is merged.\r
1037 </simpara>\r
1038 </listitem>\r
1039 <listitem>\r
1040 <simpara>\r
1041 Otherwise the remote branch of the first refspec is merged.\r
1042 </simpara>\r
1043 </listitem>\r
1044 </orderedlist>\r
1045 </simplesect>\r
1046 <simplesect id="_examples">\r
1047 <title>EXAMPLES</title>\r
1048 <itemizedlist>\r
1049 <listitem>\r
1050 <simpara>\r
1051 Update the remote-tracking branches for the repository\r
1052   you cloned from, then merge one of them into your\r
1053   current branch:\r
1054 </simpara>\r
1055 <screen>$ git pull, git pull origin</screen>\r
1056 <simpara>Normally the branch merged in is the HEAD of the remote repository,\r
1057 but the choice is determined by the branch.&lt;name&gt;.remote and\r
1058 branch.&lt;name&gt;.merge options; see <xref linkend="git-config(1)" /> for details.</simpara>\r
1059 </listitem>\r
1060 <listitem>\r
1061 <simpara>\r
1062 Merge into the current branch the remote branch <emphasis>next</emphasis>:\r
1063 </simpara>\r
1064 <screen>$ git pull origin next</screen>\r
1065 <simpara>This leaves a copy of <emphasis>next</emphasis> temporarily in FETCH_HEAD, but\r
1066 does not update any remote-tracking branches. Using remote-tracking\r
1067 branches, the same can be done by invoking fetch and merge:</simpara>\r
1068 <screen>$ git fetch origin\r
1069 $ git merge origin/next</screen>\r
1070 </listitem>\r
1071 </itemizedlist>\r
1072 <simpara>If you tried a pull which resulted in a complex conflicts and\r
1073 would want to start over, you can recover with <emphasis>git reset</emphasis>.</simpara>\r
1074 </simplesect>\r
1075 <simplesect id="_bugs">\r
1076 <title>BUGS</title>\r
1077 <simpara>Using --recurse-submodules can only fetch new commits in already checked\r
1078 out submodules right now. When e.g. upstream added a new submodule in the\r
1079 just fetched commits of the superproject the submodule itself can not be\r
1080 fetched, making it impossible to check out that submodule later without\r
1081 having to do a fetch again. This is expected to be fixed in a future git\r
1082 version.</simpara>\r
1083 </simplesect>\r
1084 <simplesect id="_see_also">\r
1085 <title>SEE ALSO</title>\r
1086 <simpara><xref linkend="git-fetch(1)" />, <xref linkend="git-merge(1)" />, <xref linkend="git-config(1)" /></simpara>\r
1087 </simplesect>\r
1088 <simplesect id="_git">\r
1089 <title>GIT</title>\r
1090 <simpara>Part of the <xref linkend="git(1)" /> suite</simpara>\r
1091 </simplesect>\r
1092 </article>\r