You are looking for the strategy recursive
with the option theirs
.
git pull -s recursive -X theirs
From the git-pull man-page:
recursive
This can only resolve two heads using a 3-way merge algorithm. When
there is more than one common ancestor that can be used for 3-way
merge, it creates a merged tree of the common ancestors 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. This is the default merge strategy when pulling or merging
one branch.
The recursive strategy can take the following options:
ours
This option forces conflicting hunks to be auto-resolved cleanly by
favoring our version. Changes from the other tree that do not
conflict with our side are reflected to the merge result. For a
binary file, the entire contents are taken from our side.
This should not be confused with the ours merge strategy, which does
not even look at what the other tree contains at all. It discards
everything the other tree did, declaring our history contains all
that happened in it.
theirs
This is the opposite of ours.
However, this is really not a good idea. Even though you trust that the changes of upstream are correct, how would you know they work with your changes that do not cause conflicts?
I personally prefer git pull --rebase
over a straight forward git pull
and inspect each conflicting commit one-by-one.