| blob | b0926e151b4a520c119ce6655e6e5c9e338282ae |
4 <head>
9 /* Debug borders */
11 /*
12 border: 1px solid red;
13 */
14 }
16 body {
18 }
20 a {
23 }
26 }
28 em {
31 }
33 strong {
36 }
38 tt {
40 }
48 }
52 }
53 h2 {
55 }
56 h3 {
58 }
59 h3 + * {
61 }
66 }
68 hr {
70 }
72 p {
75 }
79 }
81 pre {
84 }
86 span#author {
91 }
92 span#email {
93 }
96 }
98 div#footer {
104 }
105 div#footer-text {
108 }
109 div#footer-badges {
112 }
114 div#preamble {
117 }
123 }
127 }
131 }
133 /* Block element titles. */
141 }
144 }
148 }
151 }
154 }
160 }
166 }
171 }
175 }
180 }
183 }
187 }
188 /* DEPRECATED: Pre version 8.2.7 verse style literal block. */
191 }
200 }
204 }
209 }
215 dl {
218 }
219 dt {
224 }
227 }
231 }
234 }
237 }
240 }
243 }
246 }
253 }
257 }
258 thead {
261 }
262 tfoot {
264 }
267 }
270 }
271 /* Because the table frame attribute is overriden by CSS in most browsers. */
274 }
278 }
282 }
288 }
291 }
294 }
300 }
303 }
307 }
311 }
315 }
317 div#toctitle {
324 }
329 }
333 }
337 }
341 }
342 /* Overrides for manpage documents */
343 h1 {
348 }
349 h2 {
351 }
354 }
358 }
360 /* Workarounds for IE6's broken and incomplete CSS2. */
366 }
373 }
379 }
384 }
388 }
392 }
397 }
399 /* IE6 sets dynamically generated links as visited. */
401 </style>
402 </head>
403 <body>
405 <h1>
406 git-pull(1) Manual Page
407 </h1>
410 <p>git-pull -
411 Fetch from and merge with another repository or a local branch
412 </p>
413 </div>
414 </div>
418 <div class="verseblock-content"><em>git pull</em> [options] [<repository> [<refspec>…]]</div>
420 </div></div>
421 </div>
427 <div class="paragraph"><p>More precisely, <em>git pull</em> runs <em>git fetch</em> with the given
429 heads into the current branch.
433 arbitrary remote ref (for example, the name of a tag) or even
434 a collection of refs with corresponding remote-tracking branches
436 but usually it is the name of a branch in the remote repository.</p></div>
437 <div class="paragraph"><p>Default values for <repository> and <branch> are read from the
444 <pre><tt> A---B---C master on origin
445 /
446 D---E---F---G master</tt></pre>
447 </div></div>
448 <div class="paragraph"><p>Then "<tt>git pull</tt>" will fetch and replay the changes from the remote
451 result in a new commit along with the names of the two parent commits
452 and a log message from the user describing the changes.</p></div>
455 <pre><tt> A---B---C remotes/origin/master
456 / \
457 D---E---F---G---H master</tt></pre>
458 </div></div>
459 <div class="paragraph"><p>See <a href="git-merge.html">git-merge(1)</a> for details, including how conflicts
460 are presented and handled.</p></div>
462 <tt>git reset --merge</tt>. <strong>Warning</strong>: In older versions of git, running <em>git pull</em>
463 with uncommitted changes is discouraged: while possible, it leaves you
464 in a state that may be hard to back out of in the case of a conflict.</p></div>
466 the merge will be automatically cancelled and the work tree untouched.
467 It is generally best to get any local changes in working order before
469 </div>
472 <div class="paragraph"><p>Options meant for <em>git pull</em> itself and the underlying <em>git merge</em>
476 -q
477 </dt>
479 --quiet
480 </dt>
481 <dd>
482 <p>
483 This is passed to both underlying git-fetch to squelch reporting of
484 during transfer, and underlying git-merge to squelch output during
485 merging.
486 </p>
487 </dd>
489 -v
490 </dt>
492 --verbose
493 </dt>
494 <dd>
495 <p>
496 Pass --verbose to git-fetch and git-merge.
497 </p>
498 </dd>
500 --[no-]recurse-submodules[=yes|on-demand|no]
501 </dt>
502 <dd>
503 <p>
504 This option controls if new commits of all populated submodules should
505 be fetched too (see <a href="git-config.html">git-config(1)</a> and <a href="gitmodules.html">gitmodules(5)</a>).
506 That might be necessary to get the data needed for merging submodule
507 commits, a feature git learned in 1.7.3. Notice that the result of a
508 merge will not be checked out in the submodule, "git submodule update"
509 has to be called afterwards to bring the work tree up to date with the
510 merge result.
511 </p>
512 </dd>
513 </dl></div>
514 <h3 id="_options_related_to_merging">Options related to merging</h3><div style="clear:left"></div>
517 --commit
518 </dt>
520 --no-commit
521 </dt>
522 <dd>
523 <p>
524 Perform the merge and commit the result. This option can
525 be used to override --no-commit.
526 </p>
528 failed and do not autocommit, to give the user a chance to
529 inspect and further tweak the merge result before committing.</p></div>
530 </dd>
532 --ff
533 </dt>
535 --no-ff
536 </dt>
537 <dd>
538 <p>
539 Do not generate a merge commit if the merge resolved as
540 a fast-forward, only update the branch pointer. This is
541 the default behavior of git-merge.
542 </p>
544 resolved as a fast-forward.</p></div>
545 </dd>
548 </dt>
550 --no-log
551 </dt>
552 <dd>
553 <p>
554 In addition to branch names, populate the log message with
557 </p>
559 actual commits being merged.</p></div>
560 </dd>
562 --stat
563 </dt>
565 -n
566 </dt>
568 --no-stat
569 </dt>
570 <dd>
571 <p>
572 Show a diffstat at the end of the merge. The diffstat is also
573 controlled by the configuration option merge.stat.
574 </p>
576 merge.</p></div>
577 </dd>
579 --squash
580 </dt>
582 --no-squash
583 </dt>
584 <dd>
585 <p>
586 Produce the working tree and index state as if a real
587 merge happened (except for the merge information),
588 but do not actually make a commit or
591 commit. This allows you to create a single commit on
592 top of the current branch whose effect is the same as
593 merging another branch (or more in case of an octopus).
594 </p>
596 option can be used to override --squash.</p></div>
597 </dd>
599 --ff-only
600 </dt>
601 <dd>
602 <p>
603 Refuse to merge and exit with a non-zero status unless the
605 resolved as a fast-forward.
606 </p>
607 </dd>
610 </dt>
613 </dt>
614 <dd>
615 <p>
616 Use the given merge strategy; can be supplied more than
617 once to specify them in the order they should be tried.
621 </p>
622 </dd>
625 </dt>
628 </dt>
629 <dd>
630 <p>
631 Pass merge strategy specific option through to the merge
632 strategy.
633 </p>
634 </dd>
636 --summary
637 </dt>
639 --no-summary
640 </dt>
641 <dd>
642 <p>
643 Synonyms to --stat and --no-stat; these are deprecated and will be
644 removed in the future.
645 </p>
646 </dd>
648 -q
649 </dt>
651 --quiet
652 </dt>
653 <dd>
654 <p>
655 Operate quietly. Implies --no-progress.
656 </p>
657 </dd>
659 -v
660 </dt>
662 --verbose
663 </dt>
664 <dd>
665 <p>
666 Be verbose.
667 </p>
668 </dd>
670 --progress
671 </dt>
673 --no-progress
674 </dt>
675 <dd>
676 <p>
677 Turn progress on/off explicitly. If neither is specified,
678 progress is shown if standard error is connected to a terminal.
679 Note that not all merge strategies may support progress
680 reporting.
681 </p>
682 </dd>
683 </dl></div>
686 --rebase
687 </dt>
688 <dd>
689 <p>
690 Rebase the current branch on top of the upstream branch after
691 fetching. If there is a remote-tracking branch corresponding to
692 the upstream branch and the upstream branch was rebased since last
693 fetched, the rebase uses that information to avoid rebasing
694 non-local changes.
695 </p>
696 <div class="paragraph"><p>See <tt>branch.<name>.rebase</tt> and <tt>branch.autosetuprebase</tt> in
700 <table><tr>
703 </td>
705 It rewrites history, which does not bode well when you
708 </tr></table>
709 </div>
710 </dd>
712 --no-rebase
713 </dt>
714 <dd>
715 <p>
716 Override earlier --rebase.
717 </p>
718 </dd>
719 </dl></div>
720 <h3 id="_options_related_to_fetching">Options related to fetching</h3><div style="clear:left"></div>
723 --all
724 </dt>
725 <dd>
726 <p>
727 Fetch all remotes.
728 </p>
729 </dd>
731 -a
732 </dt>
734 --append
735 </dt>
736 <dd>
737 <p>
738 Append ref names and object names of fetched refs to the
741 </p>
742 </dd>
745 </dt>
746 <dd>
747 <p>
749 <tt>git clone</tt> with <tt>--depth=<depth></tt> option (see <a href="git-clone.html">git-clone(1)</a>)
750 by the specified number of commits.
751 </p>
752 </dd>
754 -f
755 </dt>
757 --force
758 </dt>
759 <dd>
760 <p>
762 refspec, it refuses to update the local branch
765 overrides that check.
766 </p>
767 </dd>
769 -k
770 </dt>
772 --keep
773 </dt>
774 <dd>
775 <p>
776 Keep downloaded pack.
777 </p>
778 </dd>
780 --no-tags
781 </dt>
782 <dd>
783 <p>
784 By default, tags that point at objects that are downloaded
785 from the remote repository are fetched and stored locally.
786 This option disables this automatic tag following. The default
789 </p>
790 </dd>
792 -u
793 </dt>
795 --update-head-ok
796 </dt>
797 <dd>
798 <p>
800 corresponds to the current branch. This flag disables the
803 implementing your own Porcelain you are not supposed to
804 use it.
805 </p>
806 </dd>
809 </dt>
810 <dd>
811 <p>
812 When given, and the repository to fetch from is handled
814 the command to specify non-default path for the command
815 run on the other end.
816 </p>
817 </dd>
819 --progress
820 </dt>
821 <dd>
822 <p>
823 Progress status is reported on the standard error stream
824 by default when it is attached to a terminal, unless -q
825 is specified. This flag forces progress status even if the
826 standard error stream is not directed to a terminal.
827 </p>
828 </dd>
831 </dt>
832 <dd>
833 <p>
834 The "remote" repository that is the source of a fetch
835 or pull operation. This parameter can be either a URL
838 </p>
839 </dd>
842 </dt>
843 <dd>
844 <p>
848 </p>
853 is updated even if it does not result in a fast-forward
854 update.</p></div>
856 <table><tr>
859 </td>
861 modified in non-linear ways such as being rewound and
862 rebased frequently, then a pull will attempt a merge with
863 an older version of itself, likely conflict, and fail.
864 It is under these conditions that you would want to use
866 be needed. There is currently no easy way to determine
867 or declare that a branch will be made available in a
868 repository with this behavior; the pulling user simply
869 must know this is the expected usage pattern for a branch.</td>
870 </tr></table>
871 </div>
873 <table><tr>
876 </td>
885 the progress of the remote side, and when you see something new
886 on the remote branch, merge it into your development branch with
888 </tr></table>
889 </div>
891 <table><tr>
894 </td>
900 merged into the current branch after fetching. In other words,
901 if you list more than one remote refs, you would be making
905 after fetching all the remote refs. This is because making an
906 Octopus from remote refs is rarely done, while keeping track
907 of multiple remote heads in one-go by fetching more than one
908 is often useful.</td>
909 </tr></table>
910 </div>
913 <li>
914 <p>
915 <tt>tag <tag></tt> means the same as <tt>refs/tags/<tag>:refs/tags/<tag></tt>;
916 it requests fetching everything up to the given tag.
917 </p>
918 </li>
919 <li>
920 <p>
923 branch without storing the remote branch anywhere locally
924 </p>
925 </li>
926 </ul></div>
927 </dd>
928 </dl></div>
929 </div>
932 <div class="paragraph"><p>In general, URLs contain information about the transport protocol, the
933 address of the remote server, and the path to the repository.
934 Depending on the transport protocol, some of this information may be
935 absent.</p></div>
937 protocols. The following syntaxes may be used with them:</p></div>
939 <li>
940 <p>
942 </p>
943 </li>
944 <li>
945 <p>
947 </p>
948 </li>
949 <li>
950 <p>
952 </p>
953 </li>
954 <li>
955 <p>
957 </p>
958 </li>
959 <li>
960 <p>
961 rsync://host.xz/path/to/repo.git/
962 </p>
963 </li>
964 </ul></div>
965 <div class="paragraph"><p>An alternative scp-like syntax may also be used with the ssh protocol:</p></div>
967 <li>
968 <p>
970 </p>
971 </li>
972 </ul></div>
973 <div class="paragraph"><p>The ssh and git protocols additionally support ~username expansion:</p></div>
975 <li>
976 <p>
978 </p>
979 </li>
980 <li>
981 <p>
983 </p>
984 </li>
985 <li>
986 <p>
988 </p>
989 </li>
990 </ul></div>
992 syntaxes may be used:</p></div>
994 <li>
995 <p>
996 /path/to/repo.git/
997 </p>
998 </li>
999 <li>
1000 <p>
1002 </p>
1003 </li>
1004 </ul></div>
1007 details.</p></div>
1008 <div class="paragraph"><p>When git doesn’t know how to handle a certain transport protocol, it
1010 exists. To explicitly request a remote helper, the following syntax
1011 may be used:</p></div>
1013 <li>
1014 <p>
1016 </p>
1017 </li>
1018 </ul></div>
1019 <div class="paragraph"><p>where <address> may be a path, a server and path, or an arbitrary
1020 URL-like string recognized by the specific remote helper being
1021 invoked. See <a href="git-remote-helpers.html">git-remote-helpers(1)</a> for details.</p></div>
1022 <div class="paragraph"><p>If there are a large number of similarly-named remote repositories and
1023 you want to use a different format for them (such that the URLs you
1024 use will be rewritten into URLs that work), you can create a
1025 configuration section of the form:</p></div>
1030 </div></div>
1035 insteadOf = host.xz:/path/to/
1036 insteadOf = work:</tt></pre>
1037 </div></div>
1038 <div class="paragraph"><p>a URL like "work:repo.git" or like "host.xz:/path/to/repo.git" will be
1041 configuration section of the form:</p></div>
1046 </div></div>
1051 pushInsteadOf = git://example.org/</tt></pre>
1052 </div></div>
1054 "ssh://example.org/path/to/repo.git" for pushes, but pulls will still
1055 use the original URL.</p></div>
1056 </div>
1062 <li>
1063 <p>
1065 </p>
1066 </li>
1067 <li>
1068 <p>
1070 </p>
1071 </li>
1072 <li>
1073 <p>
1075 </p>
1076 </li>
1077 </ul></div>
1078 <div class="paragraph"><p>All of these also allow you to omit the refspec from the command line
1079 because they each contain a refspec which git will use by default.</p></div>
1080 <h3 id="_named_remote_in_configuration_file">Named remote in configuration file</h3><div style="clear:left"></div>
1081 <div class="paragraph"><p>You can choose to provide the name of a remote which you had previously
1082 configured using <a href="git-remote.html">git-remote(1)</a>, <a href="git-config.html">git-config(1)</a>
1084 this remote will be used to access the repository. The refspec
1085 of this remote will be used by default when you do
1086 not provide a refspec on the command line. The entry in the
1087 config file would appear like this:</p></div>
1095 </div></div>
1096 <div class="paragraph"><p>The <tt><pushurl></tt> is used for pushes only. It is optional and defaults
1098 <h3 id="_named_file_in_tt_git_dir_remotes_tt">Named file in <tt>$GIT_DIR/remotes</tt></h3><div style="clear:left"></div>
1101 in this file will be used to access the repository. The refspec
1102 in this file will be used as default when you do not
1103 provide a refspec on the command line. This file should have the
1104 following format:</p></div>
1107 <pre><tt> URL: one of the above URL format
1110 </div></div>
1114 be specified for additional branch mappings.</p></div>
1115 <h3 id="_named_file_in_tt_git_dir_branches_tt">Named file in <tt>$GIT_DIR/branches</tt></h3><div style="clear:left"></div>
1118 The URL in this file will be used to access the repository.
1119 This file should have the following format:</p></div>
1123 </div></div>
1124 <div class="paragraph"><p><tt><url></tt> is required; <tt>#<head></tt> is optional.</p></div>
1126 refspecs, if you don’t provide one on the command line.
1133 </div></div>
1138 </div></div>
1139 </div>
1142 <div class="paragraph"><p>The merge mechanism (<em>git-merge</em> and <em>git-pull</em> commands) allows the
1148 resolve
1149 </dt>
1150 <dd>
1151 <p>
1152 This can only resolve two heads (i.e. the current branch
1153 and another branch you pulled from) using a 3-way merge
1154 algorithm. It tries to carefully detect criss-cross
1155 merge ambiguities and is considered generally safe and
1156 fast.
1157 </p>
1158 </dd>
1160 recursive
1161 </dt>
1162 <dd>
1163 <p>
1164 This can only resolve two heads using a 3-way merge
1165 algorithm. When there is more than one common
1166 ancestor that can be used for 3-way merge, it creates a
1167 merged tree of the common ancestors and uses that as
1168 the reference tree for the 3-way merge. This has been
1169 reported to result in fewer merge conflicts without
1170 causing mis-merges by tests done on actual merge commits
1171 taken from Linux 2.6 kernel development history.
1172 Additionally this can detect and handle merges involving
1173 renames. This is the default merge strategy when
1174 pulling or merging one branch.
1175 </p>
1176 <div class="paragraph"><p>The <em>recursive</em> strategy can take the following options:</p></div>
1179 ours
1180 </dt>
1181 <dd>
1182 <p>
1183 This option forces conflicting hunks to be auto-resolved cleanly by
1185 conflict with our side are reflected to the merge result.
1186 </p>
1187 <div class="paragraph"><p>This should not be confused with the <em>ours</em> merge strategy, which does not
1188 even look at what the other tree contains at all. It discards everything
1190 </dd>
1192 theirs
1193 </dt>
1194 <dd>
1195 <p>
1197 </p>
1198 </dd>
1200 patience
1201 </dt>
1202 <dd>
1203 <p>
1205 to avoid mismerges that sometimes occur due to unimportant
1206 matching lines (e.g., braces from distinct functions). Use
1207 this when the branches to be merged have diverged wildly.
1209 </p>
1210 </dd>
1212 ignore-space-change
1213 </dt>
1215 ignore-all-space
1216 </dt>
1218 ignore-space-at-eol
1219 </dt>
1220 <dd>
1221 <p>
1222 Treats lines with the indicated type of whitespace change as
1223 unchanged for the sake of a three-way merge. Whitespace
1224 changes mixed with other changes to a line are not ignored.
1227 </p>
1229 <li>
1230 <p>
1233 </p>
1234 </li>
1235 <li>
1236 <p>
1239 </p>
1240 </li>
1241 <li>
1242 <p>
1243 Otherwise, the merge proceeds in the usual way.
1244 </p>
1245 </li>
1246 </ul></div>
1247 </dd>
1249 renormalize
1250 </dt>
1251 <dd>
1252 <p>
1253 This runs a virtual check-out and check-in of all three stages
1254 of a file when resolving a three-way merge. This option is
1255 meant to be used when merging branches with different clean
1256 filters or end-of-line normalization rules. See "Merging
1257 branches with differing checkin/checkout attributes" in
1259 </p>
1260 </dd>
1262 no-renormalize
1263 </dt>
1264 <dd>
1265 <p>
1268 </p>
1269 </dd>
1272 </dt>
1273 <dd>
1274 <p>
1275 Controls the similarity threshold used for rename detection.
1277 </p>
1278 </dd>
1281 </dt>
1282 <dd>
1283 <p>
1285 the strategy makes a guess on how two trees must be shifted to
1286 match with each other when merging. Instead, the specified path
1287 is prefixed (or stripped from the beginning) to make the shape of
1288 two trees to match.
1289 </p>
1290 </dd>
1291 </dl></div>
1292 </dd>
1294 octopus
1295 </dt>
1296 <dd>
1297 <p>
1298 This resolves cases with more than two heads, but refuses to do
1299 a complex merge that needs manual resolution. It is
1300 primarily meant to be used for bundling topic branch
1301 heads together. This is the default merge strategy when
1302 pulling or merging more than one branch.
1303 </p>
1304 </dd>
1306 ours
1307 </dt>
1308 <dd>
1309 <p>
1310 This resolves any number of heads, but the resulting tree of the
1311 merge is always that of the current branch head, effectively
1312 ignoring all changes from all other branches. It is meant to
1313 be used to supersede old development history of side
1314 branches. Note that this is different from the -Xours option to
1316 </p>
1317 </dd>
1319 subtree
1320 </dt>
1321 <dd>
1322 <p>
1323 This is a modified recursive strategy. When merging trees A and
1324 B, if B corresponds to a subtree of A, B is first adjusted to
1325 match the tree structure of A, instead of reading the trees at
1326 the same level. This adjustment is also done to the common
1327 ancestor tree.
1328 </p>
1329 </dd>
1330 </dl></div>
1331 </div>
1335 Traditionally, this has been equivalent to saying <tt>git pull
1341 and if there is not any such variable, the value on <tt>URL: ` line
1344 optionally store in the remote-tracking branches) when the command is
1345 run without any refspec parameters on the command line, values
1348 file is consulted and its `Pull: ` lines are used.
1349 In addition to the refspec formats described in the OPTIONS
1350 section, you can have a globbing refspec that looks like this:</p></div>
1354 </div></div>
1356 what were fetched in remote-tracking branches), and its LHS and RHS
1358 branches are tracked using remote-tracking branches in
1361 fetching is a bit involved, in order not to break backward
1362 compatibility.</p></div>
1365 <div class="paragraph"><p>When no refspec was given on the command line, then <tt>git pull</tt>
1366 uses the refspec from the configuration or
1368 rules apply:</p></div>
1370 <li>
1371 <p>
1374 remote site that is merged.
1375 </p>
1376 </li>
1377 <li>
1378 <p>
1379 If the refspec is a globbing one, nothing is merged.
1380 </p>
1381 </li>
1382 <li>
1383 <p>
1384 Otherwise the remote branch of the first refspec is merged.
1385 </p>
1386 </li>
1387 </ol></div>
1388 </div>
1392 <li>
1393 <p>
1394 Update the remote-tracking branches for the repository
1395 you cloned from, then merge one of them into your
1396 current branch:
1397 </p>
1401 </div></div>
1404 branch.<name>.merge options; see <a href="git-config.html">git-config(1)</a> for details.</p></div>
1405 </li>
1406 <li>
1407 <p>
1409 </p>
1413 </div></div>
1415 does not update any remote-tracking branches. Using remote-tracking
1416 branches, the same can be done by invoking fetch and merge:</p></div>
1419 <pre><tt>$ git fetch origin
1420 $ git merge origin/next</tt></pre>
1421 </div></div>
1422 </li>
1423 </ul></div>
1426 </div>
1429 <div class="paragraph"><p>Using --recurse-submodules can only fetch new commits in already checked
1430 out submodules right now. When e.g. upstream added a new submodule in the
1431 just fetched commits of the superproject the submodule itself can not be
1432 fetched, making it impossible to check out that submodule later without
1433 having to do a fetch again. This is expected to be fixed in a future git
1434 version.</p></div>
1435 </div>
1438 <div class="paragraph"><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>
1439 </div>
1443 </div>
1447 </div>
1448 </div>
1449 </body>
1450 </html>