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

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