# 'include' dependencies
$(patsubst %.txt,%.1,$(wildcard git-diff-*.txt)): \
diff-format.txt diff-options.txt
-$(patsubst %,%.1,git-fetch git-pull git-push): pull-fetch-param.txt
$(patsubst %.txt,%.html,$(wildcard git-diff-*.txt)): \
diff-format.txt diff-options.txt
+
+$(patsubst %,%.1,git-fetch git-pull git-push): pull-fetch-param.txt
$(patsubst %,%.html,git-fetch git-pull git-push): pull-fetch-param.txt
+
+$(patsubst %,%.1,git-merge git-pull): merge-pull-opts.txt
+$(patsubst %,%.html,git-merge git-pull): merge-pull-opts.txt
+
git.7: ../README
clean:
SYNOPSIS
--------
-'git-pull' <repository> <refspec>...
+'git-pull' <options> <repository> <refspec>...
DESCRIPTION
existing contents of $GIT_DIR/FETCH_HEAD. Without this
option old data in $GIT_DIR/FETCH_HEAD will be overwritten.
+include::merge-pull-opts.txt[]
+
+
+MERGE STRATEGIES
+----------------
+
+resolve::
+ This can only resolve two heads (i.e. the current branch
+ and another branch you pulled from) using 3-way merge
+ algorithm. It tries to carefully detect criss-cross
+ merge ambiguities and is considered generally safe and
+ fast. This is the default merge strategy when pulling
+ one branch.
+
+recursive::
+ This can only resolve two heads using 3-way merge
+ algorithm. When there are more than one common
+ ancestors that can be used for 3-way merge, it creates a
+ merged tree of the common ancestores and uses that as
+ the reference tree for the 3-way merge. This has been
+ reported to result in fewer merge conflicts without
+ causing mis-merges by tests done on actual merge commits
+ taken from Linux 2.6 kernel development history.
+ Additionally this can detect and handle merges involving
+ renames.
+
+octopus::
+ This resolves more than two-head case, but refuses to do
+ complex merge that needs manual resolution. It is
+ primarily meant to be used for bundling topic branch
+ heads together. This is the default merge strategy when
+ pulling more than one branch.
+
+ours::
+ This resolves any number of heads, but the result of the
+ merge is always the current branch head. It is meant to
+ be used to supersede old development history of side
+ branches.
+
+
+EXAMPLES
+--------
+
+git pull, git pull origin::
+ Fetch the default head from the repository you cloned
+ from and merge it into your current branch.
+
+git pull -s ours . obsolete::
+ Merge local branch `obsolete` into the current branch,
+ using `ours` merge strategy.
+
+git pull . fixes enhancements::
+ Bundle local branch `fixes` and `enhancements` on top of
+ the current branch, making an Octopus merge.
+
+git pull --no-commit . maint::
+ Merge local branch `maint` into the current branch, but
+ do not make a commit automatically. This can be used
+ when you want to include further changes to the merge,
+ or want to write your own merge commit message.
++
+You should refrain from abusing this option to sneak substantial
+changes into a merge commit. Small fixups like bumping
+release/version name would be acceptable.
+
+
Author
------
Written by Linus Torvalds <torvalds@osdl.org>
projects / git.git / commitdiff