-1

I just ran a git pull origin master and many of the merge conflicts are identical in HEAD and the upstream commit:

<<<<<<< HEAD
gem 'fuzzy-string-match'
=======
gem 'fuzzy-string-match'
>>>>>>> 50147a3519be5bc883dabce86525ee4f36640b22

There are dozens of files with the same situation, where the before and after are identical.

Does anyone know what might cause this behavior? Or if there's a way to auto-merge these "conflicts"?

duhaime
  • 25,611
  • 17
  • 169
  • 224
  • Setting `merge.conflictStyle` to `diff3` shows *why* Git thinks there's a conflict here. Git is following a bunch of dumb and simple text-line rules, and when it thinks there's a conflict, there *is* a conflict, but it may be a trivial one, and probably was in this case. The conflict arises because of *three* inputs, but the default `merge` style that you got here shows you only *two of these three*, so the reason for the conflict is invisible here. – torek Jun 03 '22 at 11:39
  • My guess is that somebody removed whitespaces and amended commits rather than committing the changes into a new commit. That will cause alternative histories and such conflicts. The diff is confusing because git is not good at displaying removed whitespaces; it will only make new whitespaces visible (if color output is enabled). You could try to pull/merge again with `-Xignore-all-space` or `-Xignore-all-space` – Jay Jun 03 '22 at 12:21
  • I feel like in the past I've seen red around the deleted whitespace? My hunch is @torek is right... – duhaime Jun 03 '22 at 13:36

1 Answers1

1

Is because u have 2 head sections git doesn't know wich one is the right one that's why he shows u where conflicts are. Best way is to work with comments so he knows the difference when u merge.

Resolving merge conflicts automatically In cases when you prefer the work of other developers rather than yours, you can mention the appropriate strategy to resolve the conflicts by giving the preference to other developers' work.

git pull -s recursive -X theirs <remoterepo or other repo>

Or, simply, for the default repository:

git pull -X theirs

If you have already pulled without using the theirs strategy and want to give the preference to the work of other developers in one of the conflicting files, then run the command below:

git checkout --theirs path/to/file

If you are already in a conflicted state and want to give the preference to the work of other developers in all the conflicting files, then run the git checkout and git add commands:

git checkout --theirs .
git add .

If you give the preference to the code, written by yourself, then you should use --ours , instead of --theirs as follows:

git checkout --ours .
git add .

However, this is drastic, so make sure before running it.

You may not use the "." and type the file name in place of the dot to checkout.

You can also use the recursive --theirs strategy option with git merge:

git merge --strategy-option theirs
color
  • 86
  • 2
  • 6