1GIT-PULL(1)                       Git Manual                       GIT-PULL(1)
2
3
4

NAME

6       git-pull - Fetch from and integrate with another repository or a local
7       branch
8

SYNOPSIS

10       git pull [<options>] [<repository> [<refspec>...]]
11
12

DESCRIPTION

14       Incorporates changes from a remote repository into the current branch.
15       In its default mode, git pull is shorthand for git fetch followed by
16       git merge FETCH_HEAD.
17
18       More precisely, git pull runs git fetch with the given parameters and
19       calls git merge to merge the retrieved branch heads into the current
20       branch. With --rebase, it runs git rebase instead of git merge.
21
22       <repository> should be the name of a remote repository as passed to
23       git-fetch(1). <refspec> can name an arbitrary remote ref (for example,
24       the name of a tag) or even a collection of refs with corresponding
25       remote-tracking branches (e.g., refs/heads/*:refs/remotes/origin/*),
26       but usually it is the name of a branch in the remote repository.
27
28       Default values for <repository> and <branch> are read from the "remote"
29       and "merge" configuration for the current branch as set by git-
30       branch(1) --track.
31
32       Assume the following history exists and the current branch is "master":
33
34                     A---B---C master on origin
35                    /
36               D---E---F---G master
37                   ^
38                   origin/master in your repository
39
40
41       Then "git pull" will fetch and replay the changes from the remote
42       master branch since it diverged from the local master (i.e., E) until
43       its current commit (C) on top of master and record the result in a new
44       commit along with the names of the two parent commits and a log message
45       from the user describing the changes.
46
47                     A---B---C origin/master
48                    /         \
49               D---E---F---G---H master
50
51
52       See git-merge(1) for details, including how conflicts are presented and
53       handled.
54
55       In Git 1.7.0 or later, to cancel a conflicting merge, use git reset
56       --merge. Warning: In older versions of Git, running git pull with
57       uncommitted changes is discouraged: while possible, it leaves you in a
58       state that may be hard to back out of in the case of a conflict.
59
60       If any of the remote changes overlap with local uncommitted changes,
61       the merge will be automatically canceled and the work tree untouched.
62       It is generally best to get any local changes in working order before
63       pulling or stash them away with git-stash(1).
64

OPTIONS

66       -q, --quiet
67           This is passed to both underlying git-fetch to squelch reporting of
68           during transfer, and underlying git-merge to squelch output during
69           merging.
70
71       -v, --verbose
72           Pass --verbose to git-fetch and git-merge.
73
74       --[no-]recurse-submodules[=yes|on-demand|no]
75           This option controls if new commits of all populated submodules
76           should be fetched and updated, too (see git-config(1) and
77           gitmodules(5)).
78
79           If the checkout is done via rebase, local submodule commits are
80           rebased as well.
81
82           If the update is done via merge, the submodule conflicts are
83           resolved and checked out.
84
85   Options related to merging
86       --commit, --no-commit
87           Perform the merge and commit the result. This option can be used to
88           override --no-commit.
89
90           With --no-commit perform the merge and stop just before creating a
91           merge commit, to give the user a chance to inspect and further
92           tweak the merge result before committing.
93
94           Note that fast-forward updates do not create a merge commit and
95           therefore there is no way to stop those merges with --no-commit.
96           Thus, if you want to ensure your branch is not changed or updated
97           by the merge command, use --no-ff with --no-commit.
98
99       --edit, -e, --no-edit
100           Invoke an editor before committing successful mechanical merge to
101           further edit the auto-generated merge message, so that the user can
102           explain and justify the merge. The --no-edit option can be used to
103           accept the auto-generated message (this is generally discouraged).
104
105           Older scripts may depend on the historical behaviour of not
106           allowing the user to edit the merge log message. They will see an
107           editor opened when they run git merge. To make it easier to adjust
108           such scripts to the updated behaviour, the environment variable
109           GIT_MERGE_AUTOEDIT can be set to no at the beginning of them.
110
111       --cleanup=<mode>
112           This option determines how the merge message will be cleaned up
113           before commiting. See git-commit(1) for more details. In addition,
114           if the <mode> is given a value of scissors, scissors will be
115           appended to MERGE_MSG before being passed on to the commit
116           machinery in the case of a merge conflict.
117
118       --ff, --no-ff, --ff-only
119           Specifies how a merge is handled when the merged-in history is
120           already a descendant of the current history.  --ff is the default
121           unless merging an annotated (and possibly signed) tag that is not
122           stored in its natural place in the refs/tags/ hierarchy, in which
123           case --no-ff is assumed.
124
125           With --ff, when possible resolve the merge as a fast-forward (only
126           update the branch pointer to match the merged branch; do not create
127           a merge commit). When not possible (when the merged-in history is
128           not a descendant of the current history), create a merge commit.
129
130           With --no-ff, create a merge commit in all cases, even when the
131           merge could instead be resolved as a fast-forward.
132
133           With --ff-only, resolve the merge as a fast-forward when possible.
134           When not possible, refuse to merge and exit with a non-zero status.
135
136       -S[<keyid>], --gpg-sign[=<keyid>]
137           GPG-sign the resulting merge commit. The keyid argument is optional
138           and defaults to the committer identity; if specified, it must be
139           stuck to the option without a space.
140
141       --log[=<n>], --no-log
142           In addition to branch names, populate the log message with one-line
143           descriptions from at most <n> actual commits that are being merged.
144           See also git-fmt-merge-msg(1).
145
146           With --no-log do not list one-line descriptions from the actual
147           commits being merged.
148
149       --signoff, --no-signoff
150           Add Signed-off-by line by the committer at the end of the commit
151           log message. The meaning of a signoff depends on the project, but
152           it typically certifies that committer has the rights to submit this
153           work under the same license and agrees to a Developer Certificate
154           of Origin (see http://developercertificate.org/ for more
155           information).
156
157           With --no-signoff do not add a Signed-off-by line.
158
159       --stat, -n, --no-stat
160           Show a diffstat at the end of the merge. The diffstat is also
161           controlled by the configuration option merge.stat.
162
163           With -n or --no-stat do not show a diffstat at the end of the
164           merge.
165
166       --squash, --no-squash
167           Produce the working tree and index state as if a real merge
168           happened (except for the merge information), but do not actually
169           make a commit, move the HEAD, or record $GIT_DIR/MERGE_HEAD (to
170           cause the next git commit command to create a merge commit). This
171           allows you to create a single commit on top of the current branch
172           whose effect is the same as merging another branch (or more in case
173           of an octopus).
174
175           With --no-squash perform the merge and commit the result. This
176           option can be used to override --squash.
177
178           With --squash, --commit is not allowed, and will fail.
179
180       --no-verify
181           This option bypasses the pre-merge and commit-msg hooks. See also
182           githooks(5).
183
184       -s <strategy>, --strategy=<strategy>
185           Use the given merge strategy; can be supplied more than once to
186           specify them in the order they should be tried. If there is no -s
187           option, a built-in list of strategies is used instead (git
188           merge-recursive when merging a single head, git merge-octopus
189           otherwise).
190
191       -X <option>, --strategy-option=<option>
192           Pass merge strategy specific option through to the merge strategy.
193
194       --verify-signatures, --no-verify-signatures
195           Verify that the tip commit of the side branch being merged is
196           signed with a valid key, i.e. a key that has a valid uid: in the
197           default trust model, this means the signing key has been signed by
198           a trusted key. If the tip commit of the side branch is not signed
199           with a valid key, the merge is aborted.
200
201       --summary, --no-summary
202           Synonyms to --stat and --no-stat; these are deprecated and will be
203           removed in the future.
204
205       --allow-unrelated-histories
206           By default, git merge command refuses to merge histories that do
207           not share a common ancestor. This option can be used to override
208           this safety when merging histories of two projects that started
209           their lives independently. As that is a very rare occasion, no
210           configuration variable to enable this by default exists and will
211           not be added.
212
213       -r, --rebase[=false|true|merges|preserve|interactive]
214           When true, rebase the current branch on top of the upstream branch
215           after fetching. If there is a remote-tracking branch corresponding
216           to the upstream branch and the upstream branch was rebased since
217           last fetched, the rebase uses that information to avoid rebasing
218           non-local changes.
219
220           When set to merges, rebase using git rebase --rebase-merges so that
221           the local merge commits are included in the rebase (see git-
222           rebase(1) for details).
223
224           When set to preserve (deprecated in favor of merges), rebase with
225           the --preserve-merges option passed to git rebase so that locally
226           created merge commits will not be flattened.
227
228           When false, merge the current branch into the upstream branch.
229
230           When interactive, enable the interactive mode of rebase.
231
232           See pull.rebase, branch.<name>.rebase and branch.autoSetupRebase in
233           git-config(1) if you want to make git pull always use --rebase
234           instead of merging.
235
236               Note
237               This is a potentially dangerous mode of operation. It rewrites
238               history, which does not bode well when you published that
239               history already. Do not use this option unless you have read
240               git-rebase(1) carefully.
241
242       --no-rebase
243           Override earlier --rebase.
244
245       --autostash, --no-autostash
246           Before starting rebase, stash local modifications away (see git-
247           stash(1)) if needed, and apply the stash entry when done.
248           --no-autostash is useful to override the rebase.autoStash
249           configuration variable (see git-config(1)).
250
251           This option is only valid when "--rebase" is used.
252
253   Options related to fetching
254       --all
255           Fetch all remotes.
256
257       -a, --append
258           Append ref names and object names of fetched refs to the existing
259           contents of .git/FETCH_HEAD. Without this option old data in
260           .git/FETCH_HEAD will be overwritten.
261
262       --depth=<depth>
263           Limit fetching to the specified number of commits from the tip of
264           each remote branch history. If fetching to a shallow repository
265           created by git clone with --depth=<depth> option (see git-
266           clone(1)), deepen or shorten the history to the specified number of
267           commits. Tags for the deepened commits are not fetched.
268
269       --deepen=<depth>
270           Similar to --depth, except it specifies the number of commits from
271           the current shallow boundary instead of from the tip of each remote
272           branch history.
273
274       --shallow-since=<date>
275           Deepen or shorten the history of a shallow repository to include
276           all reachable commits after <date>.
277
278       --shallow-exclude=<revision>
279           Deepen or shorten the history of a shallow repository to exclude
280           commits reachable from a specified remote branch or tag. This
281           option can be specified multiple times.
282
283       --unshallow
284           If the source repository is complete, convert a shallow repository
285           to a complete one, removing all the limitations imposed by shallow
286           repositories.
287
288           If the source repository is shallow, fetch as much as possible so
289           that the current repository has the same history as the source
290           repository.
291
292       --update-shallow
293           By default when fetching from a shallow repository, git fetch
294           refuses refs that require updating .git/shallow. This option
295           updates .git/shallow and accept such refs.
296
297       --negotiation-tip=<commit|glob>
298           By default, Git will report, to the server, commits reachable from
299           all local refs to find common commits in an attempt to reduce the
300           size of the to-be-received packfile. If specified, Git will only
301           report commits reachable from the given tips. This is useful to
302           speed up fetches when the user knows which local ref is likely to
303           have commits in common with the upstream ref being fetched.
304
305           This option may be specified more than once; if so, Git will report
306           commits reachable from any of the given commits.
307
308           The argument to this option may be a glob on ref names, a ref, or
309           the (possibly abbreviated) SHA-1 of a commit. Specifying a glob is
310           equivalent to specifying this option multiple times, one for each
311           matching ref name.
312
313           See also the fetch.negotiationAlgorithm configuration variable
314           documented in git-config(1).
315
316       -f, --force
317           When git fetch is used with <src>:<dst> refspec it may refuse to
318           update the local branch as discussed in the <refspec> part of the
319           git-fetch(1) documentation. This option overrides that check.
320
321       -k, --keep
322           Keep downloaded pack.
323
324       --no-tags
325           By default, tags that point at objects that are downloaded from the
326           remote repository are fetched and stored locally. This option
327           disables this automatic tag following. The default behavior for a
328           remote may be specified with the remote.<name>.tagOpt setting. See
329           git-config(1).
330
331       -u, --update-head-ok
332           By default git fetch refuses to update the head which corresponds
333           to the current branch. This flag disables the check. This is purely
334           for the internal use for git pull to communicate with git fetch,
335           and unless you are implementing your own Porcelain you are not
336           supposed to use it.
337
338       --upload-pack <upload-pack>
339           When given, and the repository to fetch from is handled by git
340           fetch-pack, --exec=<upload-pack> is passed to the command to
341           specify non-default path for the command run on the other end.
342
343       --progress
344           Progress status is reported on the standard error stream by default
345           when it is attached to a terminal, unless -q is specified. This
346           flag forces progress status even if the standard error stream is
347           not directed to a terminal.
348
349       -o <option>, --server-option=<option>
350           Transmit the given string to the server when communicating using
351           protocol version 2. The given string must not contain a NUL or LF
352           character. The server’s handling of server options, including
353           unknown ones, is server-specific. When multiple
354           --server-option=<option> are given, they are all sent to the other
355           side in the order listed on the command line.
356
357       --show-forced-updates
358           By default, git checks if a branch is force-updated during fetch.
359           This can be disabled through fetch.showForcedUpdates, but the
360           --show-forced-updates option guarantees this check occurs. See git-
361           config(1).
362
363       --no-show-forced-updates
364           By default, git checks if a branch is force-updated during fetch.
365           Pass --no-show-forced-updates or set fetch.showForcedUpdates to
366           false to skip this check for performance reasons. If used during
367           git-pull the --ff-only option will still check for forced updates
368           before attempting a fast-forward update. See git-config(1).
369
370       -4, --ipv4
371           Use IPv4 addresses only, ignoring IPv6 addresses.
372
373       -6, --ipv6
374           Use IPv6 addresses only, ignoring IPv4 addresses.
375
376       <repository>
377           The "remote" repository that is the source of a fetch or pull
378           operation. This parameter can be either a URL (see the section GIT
379           URLS below) or the name of a remote (see the section REMOTES
380           below).
381
382       <refspec>
383           Specifies which refs to fetch and which local refs to update. When
384           no <refspec>s appear on the command line, the refs to fetch are
385           read from remote.<repository>.fetch variables instead (see git-
386           fetch(1)).
387
388           The format of a <refspec> parameter is an optional plus +, followed
389           by the source <src>, followed by a colon :, followed by the
390           destination ref <dst>. The colon can be omitted when <dst> is
391           empty. <src> is typically a ref, but it can also be a fully spelled
392           hex object name.
393
394           tag <tag> means the same as refs/tags/<tag>:refs/tags/<tag>; it
395           requests fetching everything up to the given tag.
396
397           The remote ref that matches <src> is fetched, and if <dst> is not
398           an empty string, an attempt is made to update the local ref that
399           matches it.
400
401           Whether that update is allowed without --force depends on the ref
402           namespace it’s being fetched to, the type of object being fetched,
403           and whether the update is considered to be a fast-forward.
404           Generally, the same rules apply for fetching as when pushing, see
405           the <refspec>...  section of git-push(1) for what those are.
406           Exceptions to those rules particular to git fetch are noted below.
407
408           Until Git version 2.20, and unlike when pushing with git-push(1),
409           any updates to refs/tags/* would be accepted without + in the
410           refspec (or --force). When fetching, we promiscuously considered
411           all tag updates from a remote to be forced fetches. Since Git
412           version 2.20, fetching to update refs/tags/* works the same way as
413           when pushing. I.e. any updates will be rejected without + in the
414           refspec (or --force).
415
416           Unlike when pushing with git-push(1), any updates outside of
417           refs/{tags,heads}/* will be accepted without + in the refspec (or
418           --force), whether that’s swapping e.g. a tree object for a blob, or
419           a commit for another commit that’s doesn’t have the previous commit
420           as an ancestor etc.
421
422           Unlike when pushing with git-push(1), there is no configuration
423           which’ll amend these rules, and nothing like a pre-fetch hook
424           analogous to the pre-receive hook.
425
426           As with pushing with git-push(1), all of the rules described above
427           about what’s not allowed as an update can be overridden by adding
428           an the optional leading + to a refspec (or using --force command
429           line option). The only exception to this is that no amount of
430           forcing will make the refs/heads/* namespace accept a non-commit
431           object.
432
433               Note
434               When the remote branch you want to fetch is known to be rewound
435               and rebased regularly, it is expected that its new tip will not
436               be descendant of its previous tip (as stored in your
437               remote-tracking branch the last time you fetched). You would
438               want to use the + sign to indicate non-fast-forward updates
439               will be needed for such branches. There is no way to determine
440               or declare that a branch will be made available in a repository
441               with this behavior; the pulling user simply must know this is
442               the expected usage pattern for a branch.
443
444               Note
445               There is a difference between listing multiple <refspec>
446               directly on git pull command line and having multiple
447               remote.<repository>.fetch entries in your configuration for a
448               <repository> and running a git pull command without any
449               explicit <refspec> parameters. <refspec>s listed explicitly on
450               the command line are always merged into the current branch
451               after fetching. In other words, if you list more than one
452               remote ref, git pull will create an Octopus merge. On the other
453               hand, if you do not list any explicit <refspec> parameter on
454               the command line, git pull will fetch all the <refspec>s it
455               finds in the remote.<repository>.fetch configuration and merge
456               only the first <refspec> found into the current branch. This is
457               because making an Octopus from remote refs is rarely done,
458               while keeping track of multiple remote heads in one-go by
459               fetching more than one is often useful.
460

GIT URLS

462       In general, URLs contain information about the transport protocol, the
463       address of the remote server, and the path to the repository. Depending
464       on the transport protocol, some of this information may be absent.
465
466       Git supports ssh, git, http, and https protocols (in addition, ftp, and
467       ftps can be used for fetching, but this is inefficient and deprecated;
468       do not use it).
469
470       The native transport (i.e. git:// URL) does no authentication and
471       should be used with caution on unsecured networks.
472
473       The following syntaxes may be used with them:
474
475       ·   ssh://[user@]host.xz[:port]/path/to/repo.git/
476
477       ·   git://host.xz[:port]/path/to/repo.git/
478
479       ·   http[s]://host.xz[:port]/path/to/repo.git/
480
481       ·   ftp[s]://host.xz[:port]/path/to/repo.git/
482
483       An alternative scp-like syntax may also be used with the ssh protocol:
484
485       ·   [user@]host.xz:path/to/repo.git/
486
487       This syntax is only recognized if there are no slashes before the first
488       colon. This helps differentiate a local path that contains a colon. For
489       example the local path foo:bar could be specified as an absolute path
490       or ./foo:bar to avoid being misinterpreted as an ssh url.
491
492       The ssh and git protocols additionally support ~username expansion:
493
494       ·   ssh://[user@]host.xz[:port]/~[user]/path/to/repo.git/
495
496       ·   git://host.xz[:port]/~[user]/path/to/repo.git/
497
498       ·   [user@]host.xz:/~[user]/path/to/repo.git/
499
500       For local repositories, also supported by Git natively, the following
501       syntaxes may be used:
502
503       ·   /path/to/repo.git/
504
505       ·   file:///path/to/repo.git/
506
507       These two syntaxes are mostly equivalent, except when cloning, when the
508       former implies --local option. See git-clone(1) for details.
509
510       When Git doesn’t know how to handle a certain transport protocol, it
511       attempts to use the remote-<transport> remote helper, if one exists. To
512       explicitly request a remote helper, the following syntax may be used:
513
514       ·   <transport>::<address>
515
516       where <address> may be a path, a server and path, or an arbitrary
517       URL-like string recognized by the specific remote helper being invoked.
518       See gitremote-helpers(7) for details.
519
520       If there are a large number of similarly-named remote repositories and
521       you want to use a different format for them (such that the URLs you use
522       will be rewritten into URLs that work), you can create a configuration
523       section of the form:
524
525                   [url "<actual url base>"]
526                           insteadOf = <other url base>
527
528
529       For example, with this:
530
531                   [url "git://git.host.xz/"]
532                           insteadOf = host.xz:/path/to/
533                           insteadOf = work:
534
535
536       a URL like "work:repo.git" or like "host.xz:/path/to/repo.git" will be
537       rewritten in any context that takes a URL to be
538       "git://git.host.xz/repo.git".
539
540       If you want to rewrite URLs for push only, you can create a
541       configuration section of the form:
542
543                   [url "<actual url base>"]
544                           pushInsteadOf = <other url base>
545
546
547       For example, with this:
548
549                   [url "ssh://example.org/"]
550                           pushInsteadOf = git://example.org/
551
552
553       a URL like "git://example.org/path/to/repo.git" will be rewritten to
554       "ssh://example.org/path/to/repo.git" for pushes, but pulls will still
555       use the original URL.
556

REMOTES

558       The name of one of the following can be used instead of a URL as
559       <repository> argument:
560
561       ·   a remote in the Git configuration file: $GIT_DIR/config,
562
563       ·   a file in the $GIT_DIR/remotes directory, or
564
565       ·   a file in the $GIT_DIR/branches directory.
566
567       All of these also allow you to omit the refspec from the command line
568       because they each contain a refspec which git will use by default.
569
570   Named remote in configuration file
571       You can choose to provide the name of a remote which you had previously
572       configured using git-remote(1), git-config(1) or even by a manual edit
573       to the $GIT_DIR/config file. The URL of this remote will be used to
574       access the repository. The refspec of this remote will be used by
575       default when you do not provide a refspec on the command line. The
576       entry in the config file would appear like this:
577
578                   [remote "<name>"]
579                           url = <url>
580                           pushurl = <pushurl>
581                           push = <refspec>
582                           fetch = <refspec>
583
584
585       The <pushurl> is used for pushes only. It is optional and defaults to
586       <url>.
587
588   Named file in $GIT_DIR/remotes
589       You can choose to provide the name of a file in $GIT_DIR/remotes. The
590       URL in this file will be used to access the repository. The refspec in
591       this file will be used as default when you do not provide a refspec on
592       the command line. This file should have the following format:
593
594                   URL: one of the above URL format
595                   Push: <refspec>
596                   Pull: <refspec>
597
598
599       Push: lines are used by git push and Pull: lines are used by git pull
600       and git fetch. Multiple Push: and Pull: lines may be specified for
601       additional branch mappings.
602
603   Named file in $GIT_DIR/branches
604       You can choose to provide the name of a file in $GIT_DIR/branches. The
605       URL in this file will be used to access the repository. This file
606       should have the following format:
607
608                   <url>#<head>
609
610
611       <url> is required; #<head> is optional.
612
613       Depending on the operation, git will use one of the following refspecs,
614       if you don’t provide one on the command line. <branch> is the name of
615       this file in $GIT_DIR/branches and <head> defaults to master.
616
617       git fetch uses:
618
619                   refs/heads/<head>:refs/heads/<branch>
620
621
622       git push uses:
623
624                   HEAD:refs/heads/<head>
625
626

MERGE STRATEGIES

628       The merge mechanism (git merge and git pull commands) allows the
629       backend merge strategies to be chosen with -s option. Some strategies
630       can also take their own options, which can be passed by giving
631       -X<option> arguments to git merge and/or git pull.
632
633       resolve
634           This can only resolve two heads (i.e. the current branch and
635           another branch you pulled from) using a 3-way merge algorithm. It
636           tries to carefully detect criss-cross merge ambiguities and is
637           considered generally safe and fast.
638
639       recursive
640           This can only resolve two heads using a 3-way merge algorithm. When
641           there is more than one common ancestor that can be used for 3-way
642           merge, it creates a merged tree of the common ancestors and uses
643           that as the reference tree for the 3-way merge. This has been
644           reported to result in fewer merge conflicts without causing
645           mismerges by tests done on actual merge commits taken from Linux
646           2.6 kernel development history. Additionally this can detect and
647           handle merges involving renames, but currently cannot make use of
648           detected copies. This is the default merge strategy when pulling or
649           merging one branch.
650
651           The recursive strategy can take the following options:
652
653           ours
654               This option forces conflicting hunks to be auto-resolved
655               cleanly by favoring our version. Changes from the other tree
656               that do not conflict with our side are reflected to the merge
657               result. For a binary file, the entire contents are taken from
658               our side.
659
660               This should not be confused with the ours merge strategy, which
661               does not even look at what the other tree contains at all. It
662               discards everything the other tree did, declaring our history
663               contains all that happened in it.
664
665           theirs
666               This is the opposite of ours; note that, unlike ours, there is
667               no theirs merge strategy to confuse this merge option with.
668
669           patience
670               With this option, merge-recursive spends a little extra time to
671               avoid mismerges that sometimes occur due to unimportant
672               matching lines (e.g., braces from distinct functions). Use this
673               when the branches to be merged have diverged wildly. See also
674               git-diff(1) --patience.
675
676           diff-algorithm=[patience|minimal|histogram|myers]
677               Tells merge-recursive to use a different diff algorithm, which
678               can help avoid mismerges that occur due to unimportant matching
679               lines (such as braces from distinct functions). See also git-
680               diff(1) --diff-algorithm.
681
682           ignore-space-change, ignore-all-space, ignore-space-at-eol,
683           ignore-cr-at-eol
684               Treats lines with the indicated type of whitespace change as
685               unchanged for the sake of a three-way merge. Whitespace changes
686               mixed with other changes to a line are not ignored. See also
687               git-diff(1) -b, -w, --ignore-space-at-eol, and
688               --ignore-cr-at-eol.
689
690               ·   If their version only introduces whitespace changes to a
691                   line, our version is used;
692
693               ·   If our version introduces whitespace changes but their
694                   version includes a substantial change, their version is
695                   used;
696
697               ·   Otherwise, the merge proceeds in the usual way.
698
699           renormalize
700               This runs a virtual check-out and check-in of all three stages
701               of a file when resolving a three-way merge. This option is
702               meant to be used when merging branches with different clean
703               filters or end-of-line normalization rules. See "Merging
704               branches with differing checkin/checkout attributes" in
705               gitattributes(5) for details.
706
707           no-renormalize
708               Disables the renormalize option. This overrides the
709               merge.renormalize configuration variable.
710
711           no-renames
712               Turn off rename detection. This overrides the merge.renames
713               configuration variable. See also git-diff(1) --no-renames.
714
715           find-renames[=<n>]
716               Turn on rename detection, optionally setting the similarity
717               threshold. This is the default. This overrides the
718               merge.renames configuration variable. See also git-diff(1)
719               --find-renames.
720
721           rename-threshold=<n>
722               Deprecated synonym for find-renames=<n>.
723
724           subtree[=<path>]
725               This option is a more advanced form of subtree strategy, where
726               the strategy makes a guess on how two trees must be shifted to
727               match with each other when merging. Instead, the specified path
728               is prefixed (or stripped from the beginning) to make the shape
729               of two trees to match.
730
731       octopus
732           This resolves cases with more than two heads, but refuses to do a
733           complex merge that needs manual resolution. It is primarily meant
734           to be used for bundling topic branch heads together. This is the
735           default merge strategy when pulling or merging more than one
736           branch.
737
738       ours
739           This resolves any number of heads, but the resulting tree of the
740           merge is always that of the current branch head, effectively
741           ignoring all changes from all other branches. It is meant to be
742           used to supersede old development history of side branches. Note
743           that this is different from the -Xours option to the recursive
744           merge strategy.
745
746       subtree
747           This is a modified recursive strategy. When merging trees A and B,
748           if B corresponds to a subtree of A, B is first adjusted to match
749           the tree structure of A, instead of reading the trees at the same
750           level. This adjustment is also done to the common ancestor tree.
751
752       With the strategies that use 3-way merge (including the default,
753       recursive), if a change is made on both branches, but later reverted on
754       one of the branches, that change will be present in the merged result;
755       some people find this behavior confusing. It occurs because only the
756       heads and the merge base are considered when performing a merge, not
757       the individual commits. The merge algorithm therefore considers the
758       reverted change as no change at all, and substitutes the changed
759       version instead.
760

DEFAULT BEHAVIOUR

762       Often people use git pull without giving any parameter. Traditionally,
763       this has been equivalent to saying git pull origin. However, when
764       configuration branch.<name>.remote is present while on branch <name>,
765       that value is used instead of origin.
766
767       In order to determine what URL to use to fetch from, the value of the
768       configuration remote.<origin>.url is consulted and if there is not any
769       such variable, the value on the URL: line in $GIT_DIR/remotes/<origin>
770       is used.
771
772       In order to determine what remote branches to fetch (and optionally
773       store in the remote-tracking branches) when the command is run without
774       any refspec parameters on the command line, values of the configuration
775       variable remote.<origin>.fetch are consulted, and if there aren’t any,
776       $GIT_DIR/remotes/<origin> is consulted and its Pull: lines are used. In
777       addition to the refspec formats described in the OPTIONS section, you
778       can have a globbing refspec that looks like this:
779
780           refs/heads/*:refs/remotes/origin/*
781
782
783       A globbing refspec must have a non-empty RHS (i.e. must store what were
784       fetched in remote-tracking branches), and its LHS and RHS must end with
785       /*. The above specifies that all remote branches are tracked using
786       remote-tracking branches in refs/remotes/origin/ hierarchy under the
787       same name.
788
789       The rule to determine which remote branch to merge after fetching is a
790       bit involved, in order not to break backward compatibility.
791
792       If explicit refspecs were given on the command line of git pull, they
793       are all merged.
794
795       When no refspec was given on the command line, then git pull uses the
796       refspec from the configuration or $GIT_DIR/remotes/<origin>. In such
797       cases, the following rules apply:
798
799        1. If branch.<name>.merge configuration for the current branch <name>
800           exists, that is the name of the branch at the remote site that is
801           merged.
802
803        2. If the refspec is a globbing one, nothing is merged.
804
805        3. Otherwise the remote branch of the first refspec is merged.
806

EXAMPLES

808       ·   Update the remote-tracking branches for the repository you cloned
809           from, then merge one of them into your current branch:
810
811               $ git pull
812               $ git pull origin
813
814           Normally the branch merged in is the HEAD of the remote repository,
815           but the choice is determined by the branch.<name>.remote and
816           branch.<name>.merge options; see git-config(1) for details.
817
818       ·   Merge into the current branch the remote branch next:
819
820               $ git pull origin next
821
822           This leaves a copy of next temporarily in FETCH_HEAD, but does not
823           update any remote-tracking branches. Using remote-tracking
824           branches, the same can be done by invoking fetch and merge:
825
826               $ git fetch origin
827               $ git merge origin/next
828
829
830       If you tried a pull which resulted in complex conflicts and would want
831       to start over, you can recover with git reset.
832

SECURITY

834       The fetch and push protocols are not designed to prevent one side from
835       stealing data from the other repository that was not intended to be
836       shared. If you have private data that you need to protect from a
837       malicious peer, your best option is to store it in another repository.
838       This applies to both clients and servers. In particular, namespaces on
839       a server are not effective for read access control; you should only
840       grant read access to a namespace to clients that you would trust with
841       read access to the entire repository.
842
843       The known attack vectors are as follows:
844
845        1. The victim sends "have" lines advertising the IDs of objects it has
846           that are not explicitly intended to be shared but can be used to
847           optimize the transfer if the peer also has them. The attacker
848           chooses an object ID X to steal and sends a ref to X, but isn’t
849           required to send the content of X because the victim already has
850           it. Now the victim believes that the attacker has X, and it sends
851           the content of X back to the attacker later. (This attack is most
852           straightforward for a client to perform on a server, by creating a
853           ref to X in the namespace the client has access to and then
854           fetching it. The most likely way for a server to perform it on a
855           client is to "merge" X into a public branch and hope that the user
856           does additional work on this branch and pushes it back to the
857           server without noticing the merge.)
858
859        2. As in #1, the attacker chooses an object ID X to steal. The victim
860           sends an object Y that the attacker already has, and the attacker
861           falsely claims to have X and not Y, so the victim sends Y as a
862           delta against X. The delta reveals regions of X that are similar to
863           Y to the attacker.
864

BUGS

866       Using --recurse-submodules can only fetch new commits in already
867       checked out submodules right now. When e.g. upstream added a new
868       submodule in the just fetched commits of the superproject the submodule
869       itself cannot be fetched, making it impossible to check out that
870       submodule later without having to do a fetch again. This is expected to
871       be fixed in a future Git version.
872

SEE ALSO

874       git-fetch(1), git-merge(1), git-config(1)
875

GIT

877       Part of the git(1) suite
878
879
880
881Git 2.24.1                        12/10/2019                       GIT-PULL(1)
Impressum