How do I run 'git pull' so that it always works, and merge collisions destroy my changes?

Question

I want to pull from a repository, and I trust that any change-sets from that repository which collide with mine, are the better option.

How do I automate the pull, so that I don't have to deal with any merge conflicts, and that the repository I'm pulling from always wins the battle?

looking at the command line options, I'm not exactly sure if git pull --squash is what I'm looking for, or if I have to apply some kind of merging strategy. I can't figure out what I would pass to

-s <strategy>
--strategy=<strategy>

or

-X <option>
--strategy-option=<option>

if that is indeed one of the flags I should be using.

Answer 1

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.