| blob | f94b2ac114a568f6e363b74c2560c5a07aac75ad |
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>
417 <div class="paragraph"><p><em>git pull</em> [options] [<repository> [<refspec>…]]</p></div>
418 </div>
424 <div class="paragraph"><p>More precisely, <em>git pull</em> runs <em>git fetch</em> with the given
426 heads into the current branch.
430 arbitrary remote ref (for example, the name of a tag) or even
431 a collection of refs with corresponding remote-tracking branches
433 but usually it is the name of a branch in the remote repository.</p></div>
434 <div class="paragraph"><p>Default values for <repository> and <branch> are read from the
441 <pre><tt> A---B---C master on origin
442 /
443 D---E---F---G master</tt></pre>
444 </div></div>
445 <div class="paragraph"><p>Then "<tt>git pull</tt>" will fetch and replay the changes from the remote
448 result in a new commit along with the names of the two parent commits
449 and a log message from the user describing the changes.</p></div>
452 <pre><tt> A---B---C remotes/origin/master
453 / \
454 D---E---F---G---H master</tt></pre>
455 </div></div>
456 <div class="paragraph"><p>See <a href="git-merge.html">git-merge(1)</a> for details, including how conflicts
457 are presented and handled.</p></div>
459 <tt>git reset --merge</tt>. <strong>Warning</strong>: In older versions of git, running <em>git pull</em>
460 with uncommitted changes is discouraged: while possible, it leaves you
461 in a state that may be hard to back out of in the case of a conflict.</p></div>
463 the merge will be automatically cancelled and the work tree untouched.
464 It is generally best to get any local changes in working order before
466 </div>
469 <div class="paragraph"><p>Options meant for <em>git pull</em> itself and the underlying <em>git merge</em>
473 -q
474 </dt>
476 --quiet
477 </dt>
478 <dd>
479 <p>
480 This is passed to both underlying git-fetch to squelch reporting of
481 during transfer, and underlying git-merge to squelch output during
482 merging.
483 </p>
484 </dd>
486 -v
487 </dt>
489 --verbose
490 </dt>
491 <dd>
492 <p>
493 Pass --verbose to git-fetch and git-merge.
494 </p>
495 </dd>
497 --[no-]recurse-submodules
498 </dt>
499 <dd>
500 <p>
501 This option controls if new commits of all populated submodules should
502 be fetched too (see <a href="git-config.html">git-config(1)</a> and <a href="gitmodules.html">gitmodules(5)</a>).
503 That might be necessary to get the data needed for merging submodule
504 commits, a feature git learned in 1.7.3. Notice that the result of a
505 merge will not be checked out in the submodule, "git submodule update"
506 has to be called afterwards to bring the work tree up to date with the
507 merge result.
508 </p>
509 </dd>
510 </dl></div>
511 <h3 id="_options_related_to_merging">Options related to merging</h3><div style="clear:left"></div>
514 --commit
515 </dt>
517 --no-commit
518 </dt>
519 <dd>
520 <p>
521 Perform the merge and commit the result. This option can
522 be used to override --no-commit.
523 </p>
525 failed and do not autocommit, to give the user a chance to
526 inspect and further tweak the merge result before committing.</p></div>
527 </dd>
529 --ff
530 </dt>
532 --no-ff
533 </dt>
534 <dd>
535 <p>
536 Do not generate a merge commit if the merge resolved as
537 a fast-forward, only update the branch pointer. This is
538 the default behavior of git-merge.
539 </p>
541 resolved as a fast-forward.</p></div>
542 </dd>
545 </dt>
547 --no-log
548 </dt>
549 <dd>
550 <p>
551 In addition to branch names, populate the log message with
554 </p>
556 actual commits being merged.</p></div>
557 </dd>
559 --stat
560 </dt>
562 -n
563 </dt>
565 --no-stat
566 </dt>
567 <dd>
568 <p>
569 Show a diffstat at the end of the merge. The diffstat is also
570 controlled by the configuration option merge.stat.
571 </p>
573 merge.</p></div>
574 </dd>
576 --squash
577 </dt>
579 --no-squash
580 </dt>
581 <dd>
582 <p>
583 Produce the working tree and index state as if a real
584 merge happened (except for the merge information),
585 but do not actually make a commit or
588 commit. This allows you to create a single commit on
589 top of the current branch whose effect is the same as
590 merging another branch (or more in case of an octopus).
591 </p>
593 option can be used to override --squash.</p></div>
594 </dd>
596 --ff-only
597 </dt>
598 <dd>
599 <p>
600 Refuse to merge and exit with a non-zero status unless the
602 resolved as a fast-forward.
603 </p>
604 </dd>
607 </dt>
610 </dt>
611 <dd>
612 <p>
613 Use the given merge strategy; can be supplied more than
614 once to specify them in the order they should be tried.
618 </p>
619 </dd>
622 </dt>
625 </dt>
626 <dd>
627 <p>
628 Pass merge strategy specific option through to the merge
629 strategy.
630 </p>
631 </dd>
633 --summary
634 </dt>
636 --no-summary
637 </dt>
638 <dd>
639 <p>
640 Synonyms to --stat and --no-stat; these are deprecated and will be
641 removed in the future.
642 </p>
643 </dd>
645 -q
646 </dt>
648 --quiet
649 </dt>
650 <dd>
651 <p>
652 Operate quietly.
653 </p>
654 </dd>
656 -v
657 </dt>
659 --verbose
660 </dt>
661 <dd>
662 <p>
663 Be verbose.
664 </p>
665 </dd>
666 </dl></div>
669 --rebase
670 </dt>
671 <dd>
672 <p>
673 Rebase the current branch on top of the upstream branch after
674 fetching. If there is a remote-tracking branch corresponding to
675 the upstream branch and the upstream branch was rebased since last
676 fetched, the rebase uses that information to avoid rebasing
677 non-local changes.
678 </p>
679 <div class="paragraph"><p>See <tt>branch.<name>.rebase</tt> and <tt>branch.autosetuprebase</tt> in
683 <table><tr>
686 </td>
688 It rewrites history, which does not bode well when you
691 </tr></table>
692 </div>
693 </dd>
695 --no-rebase
696 </dt>
697 <dd>
698 <p>
699 Override earlier --rebase.
700 </p>
701 </dd>
702 </dl></div>
703 <h3 id="_options_related_to_fetching">Options related to fetching</h3><div style="clear:left"></div>
706 --all
707 </dt>
708 <dd>
709 <p>
710 Fetch all remotes.
711 </p>
712 </dd>
714 -a
715 </dt>
717 --append
718 </dt>
719 <dd>
720 <p>
721 Append ref names and object names of fetched refs to the
724 </p>
725 </dd>
728 </dt>
729 <dd>
730 <p>
732 <tt>git clone</tt> with <tt>--depth=<depth></tt> option (see <a href="git-clone.html">git-clone(1)</a>)
733 by the specified number of commits.
734 </p>
735 </dd>
737 -f
738 </dt>
740 --force
741 </dt>
742 <dd>
743 <p>
745 refspec, it refuses to update the local branch
748 overrides that check.
749 </p>
750 </dd>
752 -k
753 </dt>
755 --keep
756 </dt>
757 <dd>
758 <p>
759 Keep downloaded pack.
760 </p>
761 </dd>
763 --no-tags
764 </dt>
765 <dd>
766 <p>
767 By default, tags that point at objects that are downloaded
768 from the remote repository are fetched and stored locally.
769 This option disables this automatic tag following. The default
772 </p>
773 </dd>
775 -u
776 </dt>
778 --update-head-ok
779 </dt>
780 <dd>
781 <p>
783 corresponds to the current branch. This flag disables the
786 implementing your own Porcelain you are not supposed to
787 use it.
788 </p>
789 </dd>
792 </dt>
793 <dd>
794 <p>
795 When given, and the repository to fetch from is handled
797 the command to specify non-default path for the command
798 run on the other end.
799 </p>
800 </dd>
802 --progress
803 </dt>
804 <dd>
805 <p>
806 Progress status is reported on the standard error stream
807 by default when it is attached to a terminal, unless -q
808 is specified. This flag forces progress status even if the
809 standard error stream is not directed to a terminal.
810 </p>
811 </dd>
814 </dt>
815 <dd>
816 <p>
817 The "remote" repository that is the source of a fetch
818 or pull operation. This parameter can be either a URL
821 </p>
822 </dd>
825 </dt>
826 <dd>
827 <p>
831 </p>
836 is updated even if it does not result in a fast-forward
837 update.</p></div>
839 <table><tr>
842 </td>
844 modified in non-linear ways such as being rewound and
845 rebased frequently, then a pull will attempt a merge with
846 an older version of itself, likely conflict, and fail.
847 It is under these conditions that you would want to use
849 be needed. There is currently no easy way to determine
850 or declare that a branch will be made available in a
851 repository with this behavior; the pulling user simply
852 must know this is the expected usage pattern for a branch.</td>
853 </tr></table>
854 </div>
856 <table><tr>
859 </td>
868 the progress of the remote side, and when you see something new
869 on the remote branch, merge it into your development branch with
871 </tr></table>
872 </div>
874 <table><tr>
877 </td>
883 merged into the current branch after fetching. In other words,
884 if you list more than one remote refs, you would be making
888 after fetching all the remote refs. This is because making an
889 Octopus from remote refs is rarely done, while keeping track
890 of multiple remote heads in one-go by fetching more than one
891 is often useful.</td>
892 </tr></table>
893 </div>
896 <li>
897 <p>
898 <tt>tag <tag></tt> means the same as <tt>refs/tags/<tag>:refs/tags/<tag></tt>;
899 it requests fetching everything up to the given tag.
900 </p>
901 </li>
902 <li>
903 <p>
906 branch without storing the remote branch anywhere locally
907 </p>
908 </li>
909 </ul></div>
910 </dd>
911 </dl></div>
912 </div>
915 <div class="paragraph"><p>In general, URLs contain information about the transport protocol, the
916 address of the remote server, and the path to the repository.
917 Depending on the transport protocol, some of this information may be
918 absent.</p></div>
920 protocols. The following syntaxes may be used with them:</p></div>
922 <li>
923 <p>
925 </p>
926 </li>
927 <li>
928 <p>
930 </p>
931 </li>
932 <li>
933 <p>
935 </p>
936 </li>
937 <li>
938 <p>
940 </p>
941 </li>
942 <li>
943 <p>
944 rsync://host.xz/path/to/repo.git/
945 </p>
946 </li>
947 </ul></div>
948 <div class="paragraph"><p>An alternative scp-like syntax may also be used with the ssh protocol:</p></div>
950 <li>
951 <p>
953 </p>
954 </li>
955 </ul></div>
956 <div class="paragraph"><p>The ssh and git protocols additionally support ~username expansion:</p></div>
958 <li>
959 <p>
961 </p>
962 </li>
963 <li>
964 <p>
966 </p>
967 </li>
968 <li>
969 <p>
971 </p>
972 </li>
973 </ul></div>
975 syntaxes may be used:</p></div>
977 <li>
978 <p>
979 /path/to/repo.git/
980 </p>
981 </li>
982 <li>
983 <p>
985 </p>
986 </li>
987 </ul></div>
990 details.</p></div>
991 <div class="paragraph"><p>When git doesn’t know how to handle a certain transport protocol, it
993 exists. To explicitly request a remote helper, the following syntax
994 may be used:</p></div>
996 <li>
997 <p>
999 </p>
1000 </li>
1001 </ul></div>
1002 <div class="paragraph"><p>where <address> may be a path, a server and path, or an arbitrary
1003 URL-like string recognized by the specific remote helper being
1004 invoked. See <a href="git-remote-helpers.html">git-remote-helpers(1)</a> for details.</p></div>
1005 <div class="paragraph"><p>If there are a large number of similarly-named remote repositories and
1006 you want to use a different format for them (such that the URLs you
1007 use will be rewritten into URLs that work), you can create a
1008 configuration section of the form:</p></div>
1013 </div></div>
1018 insteadOf = host.xz:/path/to/
1019 insteadOf = work:</tt></pre>
1020 </div></div>
1021 <div class="paragraph"><p>a URL like "work:repo.git" or like "host.xz:/path/to/repo.git" will be
1024 configuration section of the form:</p></div>
1029 </div></div>
1034 pushInsteadOf = git://example.org/</tt></pre>
1035 </div></div>
1037 "ssh://example.org/path/to/repo.git" for pushes, but pulls will still
1038 use the original URL.</p></div>
1039 </div>
1045 <li>
1046 <p>
1048 </p>
1049 </li>
1050 <li>
1051 <p>
1053 </p>
1054 </li>
1055 <li>
1056 <p>
1058 </p>
1059 </li>
1060 </ul></div>
1061 <div class="paragraph"><p>All of these also allow you to omit the refspec from the command line
1062 because they each contain a refspec which git will use by default.</p></div>
1063 <h3 id="_named_remote_in_configuration_file">Named remote in configuration file</h3><div style="clear:left"></div>
1064 <div class="paragraph"><p>You can choose to provide the name of a remote which you had previously
1065 configured using <a href="git-remote.html">git-remote(1)</a>, <a href="git-config.html">git-config(1)</a>
1067 this remote will be used to access the repository. The refspec
1068 of this remote will be used by default when you do
1069 not provide a refspec on the command line. The entry in the
1070 config file would appear like this:</p></div>
1078 </div></div>
1079 <div class="paragraph"><p>The <tt><pushurl></tt> is used for pushes only. It is optional and defaults
1081 <h3 id="_named_file_in_tt_git_dir_remotes_tt">Named file in <tt>$GIT_DIR/remotes</tt></h3><div style="clear:left"></div>
1084 in this file will be used to access the repository. The refspec
1085 in this file will be used as default when you do not
1086 provide a refspec on the command line. This file should have the
1087 following format:</p></div>
1090 <pre><tt> URL: one of the above URL format
1093 </div></div>
1097 be specified for additional branch mappings.</p></div>
1098 <h3 id="_named_file_in_tt_git_dir_branches_tt">Named file in <tt>$GIT_DIR/branches</tt></h3><div style="clear:left"></div>
1101 The URL in this file will be used to access the repository.
1102 This file should have the following format:</p></div>
1106 </div></div>
1107 <div class="paragraph"><p><tt><url></tt> is required; <tt>#<head></tt> is optional.</p></div>
1109 refspecs, if you don’t provide one on the command line.
1116 </div></div>
1121 </div></div>
1122 </div>
1125 <div class="paragraph"><p>The merge mechanism (<em>git-merge</em> and <em>git-pull</em> commands) allows the
1131 resolve
1132 </dt>
1133 <dd>
1134 <p>
1135 This can only resolve two heads (i.e. the current branch
1136 and another branch you pulled from) using a 3-way merge
1137 algorithm. It tries to carefully detect criss-cross
1138 merge ambiguities and is considered generally safe and
1139 fast.
1140 </p>
1141 </dd>
1143 recursive
1144 </dt>
1145 <dd>
1146 <p>
1147 This can only resolve two heads using a 3-way merge
1148 algorithm. When there is more than one common
1149 ancestor that can be used for 3-way merge, it creates a
1150 merged tree of the common ancestors and uses that as
1151 the reference tree for the 3-way merge. This has been
1152 reported to result in fewer merge conflicts without
1153 causing mis-merges by tests done on actual merge commits
1154 taken from Linux 2.6 kernel development history.
1155 Additionally this can detect and handle merges involving
1156 renames. This is the default merge strategy when
1157 pulling or merging one branch.
1158 </p>
1159 <div class="paragraph"><p>The <em>recursive</em> strategy can take the following options:</p></div>
1162 ours
1163 </dt>
1164 <dd>
1165 <p>
1166 This option forces conflicting hunks to be auto-resolved cleanly by
1168 conflict with our side are reflected to the merge result.
1169 </p>
1170 <div class="paragraph"><p>This should not be confused with the <em>ours</em> merge strategy, which does not
1171 even look at what the other tree contains at all. It discards everything
1173 </dd>
1175 theirs
1176 </dt>
1177 <dd>
1178 <p>
1180 </p>
1181 </dd>
1183 patience
1184 </dt>
1185 <dd>
1186 <p>
1188 to avoid mismerges that sometimes occur due to unimportant
1189 matching lines (e.g., braces from distinct functions). Use
1190 this when the branches to be merged have diverged wildly.
1192 </p>
1193 </dd>
1195 ignore-space-change
1196 </dt>
1198 ignore-all-space
1199 </dt>
1201 ignore-space-at-eol
1202 </dt>
1203 <dd>
1204 <p>
1205 Treats lines with the indicated type of whitespace change as
1206 unchanged for the sake of a three-way merge. Whitespace
1207 changes mixed with other changes to a line are not ignored.
1210 </p>
1212 <li>
1213 <p>
1216 </p>
1217 </li>
1218 <li>
1219 <p>
1222 </p>
1223 </li>
1224 <li>
1225 <p>
1226 Otherwise, the merge proceeds in the usual way.
1227 </p>
1228 </li>
1229 </ul></div>
1230 </dd>
1232 renormalize
1233 </dt>
1234 <dd>
1235 <p>
1236 This runs a virtual check-out and check-in of all three stages
1237 of a file when resolving a three-way merge. This option is
1238 meant to be used when merging branches with different clean
1239 filters or end-of-line normalization rules. See "Merging
1240 branches with differing checkin/checkout attributes" in
1242 </p>
1243 </dd>
1245 no-renormalize
1246 </dt>
1247 <dd>
1248 <p>
1251 </p>
1252 </dd>
1255 </dt>
1256 <dd>
1257 <p>
1258 Controls the similarity threshold used for rename detection.
1260 </p>
1261 </dd>
1264 </dt>
1265 <dd>
1266 <p>
1268 the strategy makes a guess on how two trees must be shifted to
1269 match with each other when merging. Instead, the specified path
1270 is prefixed (or stripped from the beginning) to make the shape of
1271 two trees to match.
1272 </p>
1273 </dd>
1274 </dl></div>
1275 </dd>
1277 octopus
1278 </dt>
1279 <dd>
1280 <p>
1281 This resolves cases with more than two heads, but refuses to do
1282 a complex merge that needs manual resolution. It is
1283 primarily meant to be used for bundling topic branch
1284 heads together. This is the default merge strategy when
1285 pulling or merging more than one branch.
1286 </p>
1287 </dd>
1289 ours
1290 </dt>
1291 <dd>
1292 <p>
1293 This resolves any number of heads, but the resulting tree of the
1294 merge is always that of the current branch head, effectively
1295 ignoring all changes from all other branches. It is meant to
1296 be used to supersede old development history of side
1297 branches. Note that this is different from the -Xours option to
1299 </p>
1300 </dd>
1302 subtree
1303 </dt>
1304 <dd>
1305 <p>
1306 This is a modified recursive strategy. When merging trees A and
1307 B, if B corresponds to a subtree of A, B is first adjusted to
1308 match the tree structure of A, instead of reading the trees at
1309 the same level. This adjustment is also done to the common
1310 ancestor tree.
1311 </p>
1312 </dd>
1313 </dl></div>
1314 </div>
1318 Traditionally, this has been equivalent to saying <tt>git pull
1324 and if there is not any such variable, the value on <tt>URL: ` line
1327 optionally store in the remote-tracking branches) when the command is
1328 run without any refspec parameters on the command line, values
1331 file is consulted and its `Pull: ` lines are used.
1332 In addition to the refspec formats described in the OPTIONS
1333 section, you can have a globbing refspec that looks like this:</p></div>
1337 </div></div>
1339 what were fetched in remote-tracking branches), and its LHS and RHS
1341 branches are tracked using remote-tracking branches in
1344 fetching is a bit involved, in order not to break backward
1345 compatibility.</p></div>
1348 <div class="paragraph"><p>When no refspec was given on the command line, then <tt>git pull</tt>
1349 uses the refspec from the configuration or
1351 rules apply:</p></div>
1353 <li>
1354 <p>
1357 remote site that is merged.
1358 </p>
1359 </li>
1360 <li>
1361 <p>
1362 If the refspec is a globbing one, nothing is merged.
1363 </p>
1364 </li>
1365 <li>
1366 <p>
1367 Otherwise the remote branch of the first refspec is merged.
1368 </p>
1369 </li>
1370 </ol></div>
1371 </div>
1375 <li>
1376 <p>
1377 Update the remote-tracking branches for the repository
1378 you cloned from, then merge one of them into your
1379 current branch:
1380 </p>
1384 </div></div>
1387 branch.<name>.merge options; see <a href="git-config.html">git-config(1)</a> for details.</p></div>
1388 </li>
1389 <li>
1390 <p>
1392 </p>
1396 </div></div>
1398 does not update any remote-tracking branches. Using remote-tracking
1399 branches, the same can be done by invoking fetch and merge:</p></div>
1402 <pre><tt>$ git fetch origin
1403 $ git merge origin/next</tt></pre>
1404 </div></div>
1405 </li>
1406 </ul></div>
1409 </div>
1412 <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>
1413 </div>
1416 <div class="paragraph"><p>Written by Linus Torvalds <<a href="mailto:torvalds@osdl.org">torvalds@osdl.org</a>>
1418 </div>
1422 David Greaves,
1423 Junio C Hamano and the git-list <<a href="mailto:git@vger.kernel.org">git@vger.kernel.org</a>>.</p></div>
1424 </div>
1428 </div>
1432 </div>
1433 </div>
1434 </body>
1435 </html>