git-pull.html

   1 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
   2     "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
   3 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
   4 <head>
   5 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
   6 <meta name="generator" content="AsciiDoc 8.2.5" />
   7 <style type="text/css">
   8 /* Debug borders */
   9 p, li, dt, dd, div, pre, h1, h2, h3, h4, h5, h6 {
  10 /*
  11   border: 1px solid red;
  12 */
  13 }
  14
  15 body {
  16   margin: 1em 5% 1em 5%;
  17 }
  18
  19 a {
  20   color: blue;
  21   text-decoration: underline;
  22 }
  23 a:visited {
  24   color: fuchsia;
  25 }
  26
  27 em {
  28   font-style: italic;
  29 }
  30
  31 strong {
  32   font-weight: bold;
  33 }
  34
  35 tt {
  36   color: navy;
  37 }
  38
  39 h1, h2, h3, h4, h5, h6 {
  40   color: #527bbd;
  41   font-family: sans-serif;
  42   margin-top: 1.2em;
  43   margin-bottom: 0.5em;
  44   line-height: 1.3;
  45 }
  46
  47 h1, h2, h3 {
  48   border-bottom: 2px solid silver;
  49 }
  50 h2 {
  51   padding-top: 0.5em;
  52 }
  53 h3 {
  54   float: left;
  55 }
  56 h3 + * {
  57   clear: left;
  58 }
  59
  60 div.sectionbody {
  61   font-family: serif;
  62   margin-left: 0;
  63 }
  64
  65 hr {
  66   border: 1px solid silver;
  67 }
  68
  69 p {
  70   margin-top: 0.5em;
  71   margin-bottom: 0.5em;
  72 }
  73
  74 pre {
  75   padding: 0;
  76   margin: 0;
  77 }
  78
  79 span#author {
  80   color: #527bbd;
  81   font-family: sans-serif;
  82   font-weight: bold;
  83   font-size: 1.1em;
  84 }
  85 span#email {
  86 }
  87 span#revision {
  88   font-family: sans-serif;
  89 }
  90
  91 div#footer {
  92   font-family: sans-serif;
  93   font-size: small;
  94   border-top: 2px solid silver;
  95   padding-top: 0.5em;
  96   margin-top: 4.0em;
  97 }
  98 div#footer-text {
  99   float: left;
 100   padding-bottom: 0.5em;
 101 }
 102 div#footer-badges {
 103   float: right;
 104   padding-bottom: 0.5em;
 105 }
 106
 107 div#preamble,
 108 div.tableblock, div.imageblock, div.exampleblock, div.verseblock,
 109 div.quoteblock, div.literalblock, div.listingblock, div.sidebarblock,
 110 div.admonitionblock {
 111   margin-right: 10%;
 112   margin-top: 1.5em;
 113   margin-bottom: 1.5em;
 114 }
 115 div.admonitionblock {
 116   margin-top: 2.5em;
 117   margin-bottom: 2.5em;
 118 }
 119
 120 div.content { /* Block element content. */
 121   padding: 0;
 122 }
 123
 124 /* Block element titles. */
 125 div.title, caption.title {
 126   font-family: sans-serif;
 127   font-weight: bold;
 128   text-align: left;
 129   margin-top: 1.0em;
 130   margin-bottom: 0.5em;
 131 }
 132 div.title + * {
 133   margin-top: 0;
 134 }
 135
 136 td div.title:first-child {
 137   margin-top: 0.0em;
 138 }
 139 div.content div.title:first-child {
 140   margin-top: 0.0em;
 141 }
 142 div.content + div.title {
 143   margin-top: 0.0em;
 144 }
 145
 146 div.sidebarblock > div.content {
 147   background: #ffffee;
 148   border: 1px solid silver;
 149   padding: 0.5em;
 150 }
 151
 152 div.listingblock {
 153   margin-right: 0%;
 154 }
 155 div.listingblock > div.content {
 156   border: 1px solid silver;
 157   background: #f4f4f4;
 158   padding: 0.5em;
 159 }
 160
 161 div.quoteblock > div.content {
 162   padding-left: 2.0em;
 163 }
 164
 165 div.attribution {
 166   text-align: right;
 167 }
 168 div.verseblock + div.attribution {
 169   text-align: left;
 170 }
 171
 172 div.admonitionblock .icon {
 173   vertical-align: top;
 174   font-size: 1.1em;
 175   font-weight: bold;
 176   text-decoration: underline;
 177   color: #527bbd;
 178   padding-right: 0.5em;
 179 }
 180 div.admonitionblock td.content {
 181   padding-left: 0.5em;
 182   border-left: 2px solid silver;
 183 }
 184
 185 div.exampleblock > div.content {
 186   border-left: 2px solid silver;
 187   padding: 0.5em;
 188 }
 189
 190 div.verseblock div.content {
 191   white-space: pre;
 192 }
 193
 194 div.imageblock div.content { padding-left: 0; }
 195 div.imageblock img { border: 1px solid silver; }
 196 span.image img { border-style: none; }
 197
 198 dl {
 199   margin-top: 0.8em;
 200   margin-bottom: 0.8em;
 201 }
 202 dt {
 203   margin-top: 0.5em;
 204   margin-bottom: 0;
 205   font-style: italic;
 206 }
 207 dd > *:first-child {
 208   margin-top: 0;
 209 }
 210
 211 ul, ol {
 212     list-style-position: outside;
 213 }
 214 div.olist2 ol {
 215   list-style-type: lower-alpha;
 216 }
 217
 218 div.tableblock > table {
 219   border: 3px solid #527bbd;
 220 }
 221 thead {
 222   font-family: sans-serif;
 223   font-weight: bold;
 224 }
 225 tfoot {
 226   font-weight: bold;
 227 }
 228
 229 div.hlist {
 230   margin-top: 0.8em;
 231   margin-bottom: 0.8em;
 232 }
 233 div.hlist td {
 234   padding-bottom: 5px;
 235 }
 236 td.hlist1 {
 237   vertical-align: top;
 238   font-style: italic;
 239   padding-right: 0.8em;
 240 }
 241 td.hlist2 {
 242   vertical-align: top;
 243 }
 244
 245 @media print {
 246   div#footer-badges { display: none; }
 247 }
 248
 249 div#toctitle {
 250   color: #527bbd;
 251   font-family: sans-serif;
 252   font-size: 1.1em;
 253   font-weight: bold;
 254   margin-top: 1.0em;
 255   margin-bottom: 0.1em;
 256 }
 257
 258 div.toclevel1, div.toclevel2, div.toclevel3, div.toclevel4 {
 259   margin-top: 0;
 260   margin-bottom: 0;
 261 }
 262 div.toclevel2 {
 263   margin-left: 2em;
 264   font-size: 0.9em;
 265 }
 266 div.toclevel3 {
 267   margin-left: 4em;
 268   font-size: 0.9em;
 269 }
 270 div.toclevel4 {
 271   margin-left: 6em;
 272   font-size: 0.9em;
 273 }
 274 include1::./stylesheets/xhtml11-manpage.css[]
 275 /* Workarounds for IE6's broken and incomplete CSS2. */
 276
 277 div.sidebar-content {
 278   background: #ffffee;
 279   border: 1px solid silver;
 280   padding: 0.5em;
 281 }
 282 div.sidebar-title, div.image-title {
 283   font-family: sans-serif;
 284   font-weight: bold;
 285   margin-top: 0.0em;
 286   margin-bottom: 0.5em;
 287 }
 288
 289 div.listingblock div.content {
 290   border: 1px solid silver;
 291   background: #f4f4f4;
 292   padding: 0.5em;
 293 }
 294
 295 div.quoteblock-content {
 296   padding-left: 2.0em;
 297 }
 298
 299 div.exampleblock-content {
 300   border-left: 2px solid silver;
 301   padding-left: 0.5em;
 302 }
 303
 304 /* IE6 sets dynamically generated links as visited. */
 305 div#toc a:visited { color: blue; }
 306 </style>
 307 <title>git-pull(1)</title>
 308 </head>
 309 <body>
 310 <div id="header">
 311 <h1>
 312 git-pull(1) Manual Page
 313 </h1>
 314 <h2>NAME</h2>
 315 <div class="sectionbody">
 316 <p>git-pull -
 317    Fetch from and merge with another repository or a local branch
 318 </p>
 319 </div>
 320 </div>
 321 <h2>SYNOPSIS</h2>
 322 <div class="sectionbody">
 323 <div class="para"><p><em>git pull</em> &lt;options&gt; &lt;repository&gt; &lt;refspec&gt;&#8230;</p></div>
 324 </div>
 325 <h2 id="_description">DESCRIPTION</h2>
 326 <div class="sectionbody">
 327 <div class="para"><p>Runs <em>git fetch</em> with the given parameters, and calls <em>git merge</em>
 328 to merge the retrieved head(s) into the current branch.
 329 With <tt>--rebase</tt>, calls <em>git rebase</em> instead of <em>git merge</em>.</p></div>
 330 <div class="para"><p>Note that you can use <tt>.</tt> (current directory) as the
 331 &lt;repository&gt; to pull from the local repository &#8212; this is useful
 332 when merging local branches into the current branch.</p></div>
 333 <div class="para"><p>Also note that options meant for <em>git pull</em> itself and underlying
 334 <em>git merge</em> must be given before the options meant for <em>git fetch</em>.</p></div>
 335 <div class="para"><p><strong>Warning</strong>: Running <em>git pull</em> (actually, the underlying <em>git merge</em>)
 336 with uncommitted changes is discouraged: while possible, it leaves you
 337 in a state that is hard to back out of in the case of a conflict.</p></div>
 338 </div>
 339 <h2 id="_options">OPTIONS</h2>
 340 <div class="sectionbody">
 341 <div class="vlist"><dl>
 342 <dt>
 343 -q
 344 </dt>
 345 <dt>
 346 --quiet
 347 </dt>
 348 <dd>
 349 <p>
 350         This is passed to both underlying git-fetch to squelch reporting of
 351         during transfer, and underlying git-merge to squelch output during
 352         merging.
 353 </p>
 354 </dd>
 355 <dt>
 356 -v
 357 </dt>
 358 <dt>
 359 --verbose
 360 </dt>
 361 <dd>
 362 <p>
 363         Pass --verbose to git-fetch and git-merge.
 364 </p>
 365 </dd>
 366 </dl></div>
 367 <h3 id="_options_related_to_merging">Options related to merging</h3><div style="clear:left"></div>
 368 <div class="vlist"><dl>
 369 <dt>
 370 --commit
 371 </dt>
 372 <dt>
 373 --no-commit
 374 </dt>
 375 <dd>
 376 <p>
 377         Perform the merge and commit the result. This option can
 378         be used to override --no-commit.
 379 </p>
 380 <div class="para"><p>With --no-commit perform the merge but pretend the merge
 381 failed and do not autocommit, to give the user a chance to
 382 inspect and further tweak the merge result before committing.</p></div>
 383 </dd>
 384 <dt>
 385 --ff
 386 </dt>
 387 <dt>
 388 --no-ff
 389 </dt>
 390 <dd>
 391 <p>
 392         Do not generate a merge commit if the merge resolved as
 393         a fast-forward, only update the branch pointer. This is
 394         the default behavior of git-merge.
 395 </p>
 396 <div class="para"><p>With --no-ff Generate a merge commit even if the merge
 397 resolved as a fast-forward.</p></div>
 398 </dd>
 399 <dt>
 400 --log
 401 </dt>
 402 <dt>
 403 --no-log
 404 </dt>
 405 <dd>
 406 <p>
 407         In addition to branch names, populate the log message with
 408         one-line descriptions from the actual commits that are being
 409         merged.
 410 </p>
 411 <div class="para"><p>With --no-log do not list one-line descriptions from the
 412 actual commits being merged.</p></div>
 413 </dd>
 414 <dt>
 415 --stat
 416 </dt>
 417 <dt>
 418 -n
 419 </dt>
 420 <dt>
 421 --no-stat
 422 </dt>
 423 <dd>
 424 <p>
 425         Show a diffstat at the end of the merge. The diffstat is also
 426         controlled by the configuration option merge.stat.
 427 </p>
 428 <div class="para"><p>With -n or --no-stat do not show a diffstat at the end of the
 429 merge.</p></div>
 430 </dd>
 431 <dt>
 432 --squash
 433 </dt>
 434 <dt>
 435 --no-squash
 436 </dt>
 437 <dd>
 438 <p>
 439         Produce the working tree and index state as if a real
 440         merge happened (except for the merge information),
 441         but do not actually make a commit or
 442         move the <tt>HEAD</tt>, nor record <tt>$GIT_DIR/MERGE_HEAD</tt> to
 443         cause the next <tt>git commit</tt> command to create a merge
 444         commit.  This allows you to create a single commit on
 445         top of the current branch whose effect is the same as
 446         merging another branch (or more in case of an octopus).
 447 </p>
 448 <div class="para"><p>With --no-squash perform the merge and commit the result. This
 449 option can be used to override --squash.</p></div>
 450 </dd>
 451 <dt>
 452 --ff-only
 453 </dt>
 454 <dd>
 455 <p>
 456         Refuse to merge and exit with a non-zero status unless the
 457         current <tt>HEAD</tt> is already up-to-date or the merge can be
 458         resolved as a fast-forward.
 459 </p>
 460 </dd>
 461 <dt>
 462 -s &lt;strategy&gt;
 463 </dt>
 464 <dt>
 465 --strategy=&lt;strategy&gt;
 466 </dt>
 467 <dd>
 468 <p>
 469         Use the given merge strategy; can be supplied more than
 470         once to specify them in the order they should be tried.
 471         If there is no <tt>-s</tt> option, a built-in list of strategies
 472         is used instead (<em>git merge-recursive</em> when merging a single
 473         head, <em>git merge-octopus</em> otherwise).
 474 </p>
 475 </dd>
 476 <dt>
 477 --summary
 478 </dt>
 479 <dt>
 480 --no-summary
 481 </dt>
 482 <dd>
 483 <p>
 484         Synonyms to --stat and --no-stat; these are deprecated and will be
 485         removed in the future.
 486 </p>
 487 </dd>
 488 <dt>
 489 -q
 490 </dt>
 491 <dt>
 492 --quiet
 493 </dt>
 494 <dd>
 495 <p>
 496         Operate quietly.
 497 </p>
 498 </dd>
 499 <dt>
 500 -v
 501 </dt>
 502 <dt>
 503 --verbose
 504 </dt>
 505 <dd>
 506 <p>
 507         Be verbose.
 508 </p>
 509 </dd>
 510 <dt>
 511 -X &lt;option&gt;
 512 </dt>
 513 <dt>
 514 --strategy-option=&lt;option&gt;
 515 </dt>
 516 <dd>
 517 <p>
 518         Pass merge strategy specific option through to the merge
 519         strategy.
 520 </p>
 521 </dd>
 522 </dl></div>
 523 <div class="vlist"><dl>
 524 <dt>
 525 --rebase
 526 </dt>
 527 <dd>
 528 <p>
 529         Instead of a merge, perform a rebase after fetching.  If
 530         there is a remote ref for the upstream branch, and this branch
 531         was rebased since last fetched, the rebase uses that information
 532         to avoid rebasing non-local changes. To make this the default
 533         for branch <tt>&lt;name&gt;</tt>, set configuration <tt>branch.&lt;name&gt;.rebase</tt>
 534         to <tt>true</tt>.
 535 </p>
 536 <div class="admonitionblock">
 537 <table><tr>
 538 <td class="icon">
 539 <div class="title">Note</div>
 540 </td>
 541 <td class="content">This is a potentially _dangerous_ mode of operation.
 542 It rewrites history, which does not bode well when you
 543 published that history already.  Do <strong>not</strong> use this option
 544 unless you have read <a href="git-rebase.html">git-rebase(1)</a> carefully.</td>
 545 </tr></table>
 546 </div>
 547 </dd>
 548 <dt>
 549 --no-rebase
 550 </dt>
 551 <dd>
 552 <p>
 553         Override earlier --rebase.
 554 </p>
 555 </dd>
 556 </dl></div>
 557 <h3 id="_options_related_to_fetching">Options related to fetching</h3><div style="clear:left"></div>
 558 <div class="vlist"><dl>
 559 <dt>
 560 --all
 561 </dt>
 562 <dd>
 563 <p>
 564         Fetch all remotes.
 565 </p>
 566 </dd>
 567 <dt>
 568 -a
 569 </dt>
 570 <dt>
 571 --append
 572 </dt>
 573 <dd>
 574 <p>
 575         Append ref names and object names of fetched refs to the
 576         existing contents of <tt>.git/FETCH_HEAD</tt>.  Without this
 577         option old data in <tt>.git/FETCH_HEAD</tt> will be overwritten.
 578 </p>
 579 </dd>
 580 <dt>
 581 --depth=&lt;depth&gt;
 582 </dt>
 583 <dd>
 584 <p>
 585         Deepen the history of a <em>shallow</em> repository created by
 586         <tt>git clone</tt> with <tt>--depth=&lt;depth&gt;</tt> option (see <a href="git-clone.html">git-clone(1)</a>)
 587         by the specified number of commits.
 588 </p>
 589 </dd>
 590 <dt>
 591 -f
 592 </dt>
 593 <dt>
 594 --force
 595 </dt>
 596 <dd>
 597 <p>
 598         When <em>git fetch</em> is used with <tt>&lt;rbranch&gt;:&lt;lbranch&gt;</tt>
 599         refspec, it refuses to update the local branch
 600         <tt>&lt;lbranch&gt;</tt> unless the remote branch <tt>&lt;rbranch&gt;</tt> it
 601         fetches is a descendant of <tt>&lt;lbranch&gt;</tt>.  This option
 602         overrides that check.
 603 </p>
 604 </dd>
 605 <dt>
 606 -k
 607 </dt>
 608 <dt>
 609 --keep
 610 </dt>
 611 <dd>
 612 <p>
 613         Keep downloaded pack.
 614 </p>
 615 </dd>
 616 <dt>
 617 --no-tags
 618 </dt>
 619 <dd>
 620 <p>
 621         By default, tags that point at objects that are downloaded
 622         from the remote repository are fetched and stored locally.
 623         This option disables this automatic tag following.
 624 </p>
 625 </dd>
 626 <dt>
 627 -t
 628 </dt>
 629 <dt>
 630 --tags
 631 </dt>
 632 <dd>
 633 <p>
 634         Most of the tags are fetched automatically as branch
 635         heads are downloaded, but tags that do not point at
 636         objects reachable from the branch heads that are being
 637         tracked will not be fetched by this mechanism.  This
 638         flag lets all tags and their associated objects be
 639         downloaded.
 640 </p>
 641 </dd>
 642 <dt>
 643 -u
 644 </dt>
 645 <dt>
 646 --update-head-ok
 647 </dt>
 648 <dd>
 649 <p>
 650         By default <em>git fetch</em> refuses to update the head which
 651         corresponds to the current branch.  This flag disables the
 652         check.  This is purely for the internal use for <em>git pull</em>
 653         to communicate with <em>git fetch</em>, and unless you are
 654         implementing your own Porcelain you are not supposed to
 655         use it.
 656 </p>
 657 </dd>
 658 <dt>
 659 --upload-pack &lt;upload-pack&gt;
 660 </dt>
 661 <dd>
 662 <p>
 663         When given, and the repository to fetch from is handled
 664         by <em>git fetch-pack</em>, <em>--exec=&lt;upload-pack&gt;</em> is passed to
 665         the command to specify non-default path for the command
 666         run on the other end.
 667 </p>
 668 </dd>
 669 <dt>
 670 --progress
 671 </dt>
 672 <dd>
 673 <p>
 674         Progress status is reported on the standard error stream
 675         by default when it is attached to a terminal, unless -q
 676         is specified. This flag forces progress status even if the
 677         standard error stream is not directed to a terminal.
 678 </p>
 679 </dd>
 680 <dt>
 681 &lt;repository&gt;
 682 </dt>
 683 <dd>
 684 <p>
 685         The "remote" repository that is the source of a fetch
 686         or pull operation.  This parameter can be either a URL
 687         (see the section <a href="#URLS">GIT URLS</a> below) or the name
 688         of a remote (see the section <a href="#REMOTES">REMOTES</a> below).
 689 </p>
 690 </dd>
 691 <dt>
 692 &lt;refspec&gt;
 693 </dt>
 694 <dd>
 695 <p>
 696         The format of a &lt;refspec&gt; parameter is an optional plus
 697         <tt>&#43;</tt>, followed by the source ref &lt;src&gt;, followed
 698         by a colon <tt>:</tt>, followed by the destination ref &lt;dst&gt;.
 699 </p>
 700 <div class="para"><p>The remote ref that matches &lt;src&gt;
 701 is fetched, and if &lt;dst&gt; is not empty string, the local
 702 ref that matches it is fast-forwarded using &lt;src&gt;.
 703 If the optional plus <tt>+</tt> is used, the local ref
 704 is updated even if it does not result in a fast-forward
 705 update.</p></div>
 706 <div class="admonitionblock">
 707 <table><tr>
 708 <td class="icon">
 709 <div class="title">Note</div>
 710 </td>
 711 <td class="content">If the remote branch from which you want to pull is
 712 modified in non-linear ways such as being rewound and
 713 rebased frequently, then a pull will attempt a merge with
 714 an older version of itself, likely conflict, and fail.
 715 It is under these conditions that you would want to use
 716 the <tt>+</tt> sign to indicate non-fast-forward updates will
 717 be needed.  There is currently no easy way to determine
 718 or declare that a branch will be made available in a
 719 repository with this behavior; the pulling user simply
 720 must know this is the expected usage pattern for a branch.</td>
 721 </tr></table>
 722 </div>
 723 <div class="admonitionblock">
 724 <table><tr>
 725 <td class="icon">
 726 <div class="title">Note</div>
 727 </td>
 728 <td class="content">You never do your own development on branches that appear
 729 on the right hand side of a &lt;refspec&gt; colon on <tt>Pull:</tt> lines;
 730 they are to be updated by <em>git fetch</em>.  If you intend to do
 731 development derived from a remote branch <tt>B</tt>, have a <tt>Pull:</tt>
 732 line to track it (i.e. <tt>Pull: B:remote-B</tt>), and have a separate
 733 branch <tt>my-B</tt> to do your development on top of it.  The latter
 734 is created by <tt>git branch my-B remote-B</tt> (or its equivalent <tt>git
 735 checkout -b my-B remote-B</tt>).  Run <tt>git fetch</tt> to keep track of
 736 the progress of the remote side, and when you see something new
 737 on the remote branch, merge it into your development branch with
 738 <tt>git pull . remote-B</tt>, while you are on <tt>my-B</tt> branch.</td>
 739 </tr></table>
 740 </div>
 741 <div class="admonitionblock">
 742 <table><tr>
 743 <td class="icon">
 744 <div class="title">Note</div>
 745 </td>
 746 <td class="content">There is a difference between listing multiple &lt;refspec&gt;
 747 directly on <em>git pull</em> command line and having multiple
 748 <tt>Pull:</tt> &lt;refspec&gt; lines for a &lt;repository&gt; and running
 749 <em>git pull</em> command without any explicit &lt;refspec&gt; parameters.
 750 &lt;refspec&gt; listed explicitly on the command line are always
 751 merged into the current branch after fetching.  In other words,
 752 if you list more than one remote refs, you would be making
 753 an Octopus.  While <em>git pull</em> run without any explicit &lt;refspec&gt;
 754 parameter takes default &lt;refspec&gt;s from <tt>Pull:</tt> lines, it
 755 merges only the first &lt;refspec&gt; found into the current branch,
 756 after fetching all the remote refs.  This is because making an
 757 Octopus from remote refs is rarely done, while keeping track
 758 of multiple remote heads in one-go by fetching more than one
 759 is often useful.</td>
 760 </tr></table>
 761 </div>
 762 <div class="para"><p>Some short-cut notations are also supported.</p></div>
 763 <div class="ilist"><ul>
 764 <li>
 765 <p>
 766 <tt>tag &lt;tag&gt;</tt> means the same as <tt>refs/tags/&lt;tag&gt;:refs/tags/&lt;tag&gt;</tt>;
 767   it requests fetching everything up to the given tag.
 768 </p>
 769 </li>
 770 <li>
 771 <p>
 772 A parameter &lt;ref&gt; without a colon is equivalent to
 773   &lt;ref&gt;: when pulling/fetching, so it merges &lt;ref&gt; into the current
 774   branch without storing the remote branch anywhere locally
 775 </p>
 776 </li>
 777 </ul></div>
 778 </dd>
 779 </dl></div>
 780 </div>
 781 <h2 id="_git_urls_a_id_urls_a">GIT URLS<a id="URLS"></a></h2>
 782 <div class="sectionbody">
 783 <div class="para"><p>One of the following notations can be used
 784 to name the remote repository:</p></div>
 785 <div class="ilist"><ul>
 786 <li>
 787 <p>
 788 rsync://host.xz/path/to/repo.git/
 789 </p>
 790 </li>
 791 <li>
 792 <p>
 793 http://host.xz&#91;:port&#93;/path/to/repo.git/
 794 </p>
 795 </li>
 796 <li>
 797 <p>
 798 https://host.xz&#91;:port&#93;/path/to/repo.git/
 799 </p>
 800 </li>
 801 <li>
 802 <p>
 803 git://host.xz&#91;:port&#93;/path/to/repo.git/
 804 </p>
 805 </li>
 806 <li>
 807 <p>
 808 git://host.xz&#91;:port&#93;/~user/path/to/repo.git/
 809 </p>
 810 </li>
 811 <li>
 812 <p>
 813 ssh://&#91;user@&#93;host.xz&#91;:port&#93;/path/to/repo.git/
 814 </p>
 815 </li>
 816 <li>
 817 <p>
 818 ssh://&#91;user@&#93;host.xz/path/to/repo.git/
 819 </p>
 820 </li>
 821 <li>
 822 <p>
 823 ssh://&#91;user@&#93;host.xz/~user/path/to/repo.git/
 824 </p>
 825 </li>
 826 <li>
 827 <p>
 828 ssh://&#91;user@&#93;host.xz/~/path/to/repo.git
 829 </p>
 830 </li>
 831 </ul></div>
 832 <div class="para"><p>SSH is the default transport protocol over the network.  You can
 833 optionally specify which user to log-in as, and an alternate,
 834 scp-like syntax is also supported.  Both syntaxes support
 835 username expansion, as does the native git protocol, but
 836 only the former supports port specification. The following
 837 three are identical to the last three above, respectively:</p></div>
 838 <div class="ilist"><ul>
 839 <li>
 840 <p>
 841 &#91;user@&#93;host.xz:/path/to/repo.git/
 842 </p>
 843 </li>
 844 <li>
 845 <p>
 846 &#91;user@&#93;host.xz:~user/path/to/repo.git/
 847 </p>
 848 </li>
 849 <li>
 850 <p>
 851 &#91;user@&#93;host.xz:path/to/repo.git
 852 </p>
 853 </li>
 854 </ul></div>
 855 <div class="para"><p>To sync with a local directory, you can use:</p></div>
 856 <div class="ilist"><ul>
 857 <li>
 858 <p>
 859 /path/to/repo.git/
 860 </p>
 861 </li>
 862 <li>
 863 <p>
 864 file:///path/to/repo.git/
 865 </p>
 866 </li>
 867 </ul></div>
 868 <div class="para"><p>They are mostly equivalent, except when cloning.  See
 869 <a href="git-clone.html">git-clone(1)</a> for details.</p></div>
 870 <div class="para"><p>If there are a large number of similarly-named remote repositories and
 871 you want to use a different format for them (such that the URLs you
 872 use will be rewritten into URLs that work), you can create a
 873 configuration section of the form:</p></div>
 874 <div class="listingblock">
 875 <div class="content">
 876 <pre><tt>        [url "&lt;actual url base&gt;"]
 877                 insteadOf = &lt;other url base&gt;</tt></pre>
 878 </div></div>
 879 <div class="para"><p>For example, with this:</p></div>
 880 <div class="listingblock">
 881 <div class="content">
 882 <pre><tt>        [url "git://git.host.xz/"]
 883                 insteadOf = host.xz:/path/to/
 884                 insteadOf = work:</tt></pre>
 885 </div></div>
 886 <div class="para"><p>a URL like "work:repo.git" or like "host.xz:/path/to/repo.git" will be
 887 rewritten in any context that takes a URL to be "git://git.host.xz/repo.git".</p></div>
 888 <div class="para"><p>If you want to rewrite URLs for push only, you can create a
 889 configuration section of the form:</p></div>
 890 <div class="listingblock">
 891 <div class="content">
 892 <pre><tt>        [url "&lt;actual url base&gt;"]
 893                 pushInsteadOf = &lt;other url base&gt;</tt></pre>
 894 </div></div>
 895 <div class="para"><p>For example, with this:</p></div>
 896 <div class="listingblock">
 897 <div class="content">
 898 <pre><tt>        [url "ssh://example.org/"]
 899                 pushInsteadOf = git://example.org/</tt></pre>
 900 </div></div>
 901 <div class="para"><p>a URL like "git://example.org/path/to/repo.git" will be rewritten to
 902 "ssh://example.org/path/to/repo.git" for pushes, but pulls will still
 903 use the original URL.</p></div>
 904 </div>
 905 <h2 id="_remotes_a_id_remotes_a">REMOTES<a id="REMOTES"></a></h2>
 906 <div class="sectionbody">
 907 <div class="para"><p>The name of one of the following can be used instead
 908 of a URL as <tt>&lt;repository&gt;</tt> argument:</p></div>
 909 <div class="ilist"><ul>
 910 <li>
 911 <p>
 912 a remote in the git configuration file: <tt>$GIT_DIR/config</tt>,
 913 </p>
 914 </li>
 915 <li>
 916 <p>
 917 a file in the <tt>$GIT_DIR/remotes</tt> directory, or
 918 </p>
 919 </li>
 920 <li>
 921 <p>
 922 a file in the <tt>$GIT_DIR/branches</tt> directory.
 923 </p>
 924 </li>
 925 </ul></div>
 926 <div class="para"><p>All of these also allow you to omit the refspec from the command line
 927 because they each contain a refspec which git will use by default.</p></div>
 928 <h3 id="_named_remote_in_configuration_file">Named remote in configuration file</h3><div style="clear:left"></div>
 929 <div class="para"><p>You can choose to provide the name of a remote which you had previously
 930 configured using <a href="git-remote.html">git-remote(1)</a>, <a href="git-config.html">git-config(1)</a>
 931 or even by a manual edit to the <tt>$GIT_DIR/config</tt> file.  The URL of
 932 this remote will be used to access the repository.  The refspec
 933 of this remote will be used by default when you do
 934 not provide a refspec on the command line.  The entry in the
 935 config file would appear like this:</p></div>
 936 <div class="listingblock">
 937 <div class="content">
 938 <pre><tt>        [remote "&lt;name&gt;"]
 939                 url = &lt;url&gt;
 940                 pushurl = &lt;pushurl&gt;
 941                 push = &lt;refspec&gt;
 942                 fetch = &lt;refspec&gt;</tt></pre>
 943 </div></div>
 944 <div class="para"><p>The <tt>&lt;pushurl&gt;</tt> is used for pushes only. It is optional and defaults
 945 to <tt>&lt;url&gt;</tt>.</p></div>
 946 <h3 id="_named_file_in_tt_git_dir_remotes_tt">Named file in <tt>$GIT_DIR/remotes</tt></h3><div style="clear:left"></div>
 947 <div class="para"><p>You can choose to provide the name of a
 948 file in <tt>$GIT_DIR/remotes</tt>.  The URL
 949 in this file will be used to access the repository.  The refspec
 950 in this file will be used as default when you do not
 951 provide a refspec on the command line.  This file should have the
 952 following format:</p></div>
 953 <div class="listingblock">
 954 <div class="content">
 955 <pre><tt>        URL: one of the above URL format
 956         Push: &lt;refspec&gt;
 957         Pull: &lt;refspec&gt;
 958 </tt></pre>
 959 </div></div>
 960 <div class="para"><p><tt>Push:</tt> lines are used by <em>git push</em> and
 961 <tt>Pull:</tt> lines are used by <em>git pull</em> and <em>git fetch</em>.
 962 Multiple <tt>Push:</tt> and <tt>Pull:</tt> lines may
 963 be specified for additional branch mappings.</p></div>
 964 <h3 id="_named_file_in_tt_git_dir_branches_tt">Named file in <tt>$GIT_DIR/branches</tt></h3><div style="clear:left"></div>
 965 <div class="para"><p>You can choose to provide the name of a
 966 file in <tt>$GIT_DIR/branches</tt>.
 967 The URL in this file will be used to access the repository.
 968 This file should have the following format:</p></div>
 969 <div class="listingblock">
 970 <div class="content">
 971 <pre><tt>        &lt;url&gt;#&lt;head&gt;</tt></pre>
 972 </div></div>
 973 <div class="para"><p><tt>&lt;url&gt;</tt> is required; <tt>#&lt;head&gt;</tt> is optional.</p></div>
 974 <div class="para"><p>Depending on the operation, git will use one of the following
 975 refspecs, if you don't provide one on the command line.
 976 <tt>&lt;branch&gt;</tt> is the name of this file in <tt>$GIT_DIR/branches</tt> and
 977 <tt>&lt;head&gt;</tt> defaults to <tt>master</tt>.</p></div>
 978 <div class="para"><p>git fetch uses:</p></div>
 979 <div class="listingblock">
 980 <div class="content">
 981 <pre><tt>        refs/heads/&lt;head&gt;:refs/heads/&lt;branch&gt;</tt></pre>
 982 </div></div>
 983 <div class="para"><p>git push uses:</p></div>
 984 <div class="listingblock">
 985 <div class="content">
 986 <pre><tt>        HEAD:refs/heads/&lt;head&gt;</tt></pre>
 987 </div></div>
 988 </div>
 989 <h2 id="_merge_strategies">MERGE STRATEGIES</h2>
 990 <div class="sectionbody">
 991 <div class="para"><p>The merge mechanism (<em>git-merge</em> and <em>git-pull</em> commands) allows the
 992 backend <em>merge strategies</em> to be chosen with <tt>-s</tt> option.  Some strategies
 993 can also take their own options, which can be passed by giving <tt>-X&lt;option&gt;</tt>
 994 arguments to <em>git-merge</em> and/or <em>git-pull</em>.</p></div>
 995 <div class="vlist"><dl>
 996 <dt>
 997 resolve
 998 </dt>
 999 <dd>
1000 <p>
1001         This can only resolve two heads (i.e. the current branch
1002         and another branch you pulled from) using a 3-way merge
1003         algorithm.  It tries to carefully detect criss-cross
1004         merge ambiguities and is considered generally safe and
1005         fast.
1006 </p>
1007 </dd>
1008 <dt>
1009 recursive
1010 </dt>
1011 <dd>
1012 <p>
1013         This can only resolve two heads using a 3-way merge
1014         algorithm.  When there is more than one common
1015         ancestor that can be used for 3-way merge, it creates a
1016         merged tree of the common ancestors and uses that as
1017         the reference tree for the 3-way merge.  This has been
1018         reported to result in fewer merge conflicts without
1019         causing mis-merges by tests done on actual merge commits
1020         taken from Linux 2.6 kernel development history.
1021         Additionally this can detect and handle merges involving
1022         renames.  This is the default merge strategy when
1023         pulling or merging one branch.
1024 </p>
1025 <div class="para"><p>The <em>recursive</em> strategy can take the following options:</p></div>
1026 <div class="vlist"><dl>
1027 <dt>
1028 ours
1029 </dt>
1030 <dd>
1031 <p>
1032         This option forces conflicting hunks to be auto-resolved cleanly by
1033         favoring <em>our</em> version.  Changes from the other tree that do not
1034         conflict with our side are reflected to the merge result.
1035 </p>
1036 <div class="para"><p>This should not be confused with the <em>ours</em> merge strategy, which does not
1037 even look at what the other tree contains at all.  It discards everything
1038 the other tree did, declaring <em>our</em> history contains all that happened in it.</p></div>
1039 </dd>
1040 <dt>
1041 theirs
1042 </dt>
1043 <dd>
1044 <p>
1045         This is opposite of <em>ours</em>.
1046 </p>
1047 </dd>
1048 <dt>
1049 subtree[=path]
1050 </dt>
1051 <dd>
1052 <p>
1053         This option is a more advanced form of <em>subtree</em> strategy, where
1054         the strategy makes a guess on how two trees must be shifted to
1055         match with each other when merging.  Instead, the specified path
1056         is prefixed (or stripped from the beginning) to make the shape of
1057         two trees to match.
1058 </p>
1059 </dd>
1060 </dl></div>
1061 </dd>
1062 <dt>
1063 octopus
1064 </dt>
1065 <dd>
1066 <p>
1067         This resolves cases with more than two heads, but refuses to do
1068         a complex merge that needs manual resolution.  It is
1069         primarily meant to be used for bundling topic branch
1070         heads together.  This is the default merge strategy when
1071         pulling or merging more than one branch.
1072 </p>
1073 </dd>
1074 <dt>
1075 ours
1076 </dt>
1077 <dd>
1078 <p>
1079         This resolves any number of heads, but the resulting tree of the
1080         merge is always that of the current branch head, effectively
1081         ignoring all changes from all other branches.  It is meant to
1082         be used to supersede old development history of side
1083         branches.  Note that this is different from the -Xours option to
1084         the <em>recursive</em> merge strategy.
1085 </p>
1086 </dd>
1087 <dt>
1088 subtree
1089 </dt>
1090 <dd>
1091 <p>
1092         This is a modified recursive strategy. When merging trees A and
1093         B, if B corresponds to a subtree of A, B is first adjusted to
1094         match the tree structure of A, instead of reading the trees at
1095         the same level. This adjustment is also done to the common
1096         ancestor tree.
1097 </p>
1098 </dd>
1099 </dl></div>
1100 </div>
1101 <h2 id="_default_behaviour">DEFAULT BEHAVIOUR</h2>
1102 <div class="sectionbody">
1103 <div class="para"><p>Often people use <tt>git pull</tt> without giving any parameter.
1104 Traditionally, this has been equivalent to saying <tt>git pull
1105 origin</tt>.  However, when configuration <tt>branch.&lt;name&gt;.remote</tt> is
1106 present while on branch <tt>&lt;name&gt;</tt>, that value is used instead of
1107 <tt>origin</tt>.</p></div>
1108 <div class="para"><p>In order to determine what URL to use to fetch from, the value
1109 of the configuration <tt>remote.&lt;origin&gt;.url</tt> is consulted
1110 and if there is not any such variable, the value on <tt>URL: </tt> line
1111 in <tt>$GIT_DIR/remotes/&lt;origin&gt;</tt> file is used.</p></div>
1112 <div class="para"><p>In order to determine what remote branches to fetch (and
1113 optionally store in the tracking branches) when the command is
1114 run without any refspec parameters on the command line, values
1115 of the configuration variable <tt>remote.&lt;origin&gt;.fetch</tt> are
1116 consulted, and if there aren't any, <tt>$GIT_DIR/remotes/&lt;origin&gt;</tt>
1117 file is consulted and its <tt>Pull: </tt> lines are used.
1118 In addition to the refspec formats described in the OPTIONS
1119 section, you can have a globbing refspec that looks like this:</p></div>
1120 <div class="listingblock">
1121 <div class="content">
1122 <pre><tt>refs/heads/*:refs/remotes/origin/*</tt></pre>
1123 </div></div>
1124 <div class="para"><p>A globbing refspec must have a non-empty RHS (i.e. must store
1125 what were fetched in tracking branches), and its LHS and RHS
1126 must end with <tt>/*</tt>.  The above specifies that all remote
1127 branches are tracked using tracking branches in
1128 <tt>refs/remotes/origin/</tt> hierarchy under the same name.</p></div>
1129 <div class="para"><p>The rule to determine which remote branch to merge after
1130 fetching is a bit involved, in order not to break backward
1131 compatibility.</p></div>
1132 <div class="para"><p>If explicit refspecs were given on the command
1133 line of <tt>git pull</tt>, they are all merged.</p></div>
1134 <div class="para"><p>When no refspec was given on the command line, then <tt>git pull</tt>
1135 uses the refspec from the configuration or
1136 <tt>$GIT_DIR/remotes/&lt;origin&gt;</tt>.  In such cases, the following
1137 rules apply:</p></div>
1138 <div class="olist"><ol>
1139 <li>
1140 <p>
1141 If <tt>branch.&lt;name&gt;.merge</tt> configuration for the current
1142   branch <tt>&lt;name&gt;</tt> exists, that is the name of the branch at the
1143   remote site that is merged.
1144 </p>
1145 </li>
1146 <li>
1147 <p>
1148 If the refspec is a globbing one, nothing is merged.
1149 </p>
1150 </li>
1151 <li>
1152 <p>
1153 Otherwise the remote branch of the first refspec is merged.
1154 </p>
1155 </li>
1156 </ol></div>
1157 </div>
1158 <h2 id="_examples">EXAMPLES</h2>
1159 <div class="sectionbody">
1160 <div class="ilist"><ul>
1161 <li>
1162 <p>
1163 Update the remote-tracking branches for the repository
1164   you cloned from, then merge one of them into your
1165   current branch:
1166 </p>
1167 <div class="listingblock">
1168 <div class="content">
1169 <pre><tt>$ git pull, git pull origin</tt></pre>
1170 </div></div>
1171 <div class="para"><p>Normally the branch merged in is the HEAD of the remote repository,
1172 but the choice is determined by the branch.&lt;name&gt;.remote and
1173 branch.&lt;name&gt;.merge options; see <a href="git-config.html">git-config(1)</a> for details.</p></div>
1174 </li>
1175 <li>
1176 <p>
1177 Merge into the current branch the remote branch <tt>next</tt>:
1178 </p>
1179 <div class="listingblock">
1180 <div class="content">
1181 <pre><tt>$ git pull origin next</tt></pre>
1182 </div></div>
1183 <div class="para"><p>This leaves a copy of <tt>next</tt> temporarily in FETCH_HEAD, but
1184 does not update any remote-tracking branches. Using remote-tracking
1185 branches, the same can be done by invoking fetch and merge:</p></div>
1186 <div class="listingblock">
1187 <div class="content">
1188 <pre><tt>$ git fetch origin
1189 $ git merge origin/next</tt></pre>
1190 </div></div>
1191 </li>
1192 </ul></div>
1193 <div class="para"><p>If you tried a pull which resulted in a complex conflicts and
1194 would want to start over, you can recover with <em>git reset</em>.</p></div>
1195 </div>
1196 <h2 id="_see_also">SEE ALSO</h2>
1197 <div class="sectionbody">
1198 <div class="para"><p><a href="git-fetch.html">git-fetch(1)</a>, <a href="git-merge.html">git-merge(1)</a>, <a href="git-config.html">git-config(1)</a></p></div>
1199 </div>
1200 <h2 id="_author">Author</h2>
1201 <div class="sectionbody">
1202 <div class="para"><p>Written by Linus Torvalds &lt;torvalds@osdl.org&gt;
1203 and Junio C Hamano &lt;gitster@pobox.com&gt;</p></div>
1204 </div>
1205 <h2 id="_documentation">Documentation</h2>
1206 <div class="sectionbody">
1207 <div class="para"><p>Documentation by Jon Loeliger,
1208 David Greaves,
1209 Junio C Hamano and the git-list &lt;git@vger.kernel.org&gt;.</p></div>
1210 </div>
1211 <h2 id="_git">GIT</h2>
1212 <div class="sectionbody">
1213 <div class="para"><p>Part of the <a href="git.html">git(1)</a> suite</p></div>
1214 </div>
1215 <div id="footer">
1216 <div id="footer-text">
1217 Last updated 2010-03-22 01:47:15 UTC
1218 </div>
1219 </div>
1220 </body>
1221 </html>