Git merge conflicts on files that are NOT changed

Question

I went through the following questions already:

But I found no reasonable explanation. So trying to open a new thread.

Problem: When I merge 'master' to my developer branch (dev-branch), I get merge conflicts on files that are NOT modified by me on dev-branch.

Procedure:

git checkout master
git pull --ff-only (Update the master branch to the latest changes)
git checkout dev-branch
git merge --squash master
Results in conflicts on files not modified by me

Questions:

Why do I see the conflicts ?
Why cannot GIT resolve them automatically since there are no changes on my branch ?
What can I do to avoid these conflicts ?

===EDIT: 12th June 2019===

I started to observe my merge behavior to narrow down on the issue and found the following. Whenever I am developing something that takes long time, I tend to update my development branch often to avoid having to do a single big shot merge.

If I was working on branch say, dev_branch, I used to merge master to dev_branch, and continue my development, and repeat this step every once in a while. But what I found useful is to actually merge dev_branch to master and branch out from it again to a new development branch dev_branch_1 (note that I am not commiting anything on master yet since the development is not complete) and continue development on the new branch. This seems to work for me so far to avoid these nasty merge conflicts.

Could it be that you got line endings wrong? Because the reason you get conflicts is because the files *are* changed. — Lasse V. Karlsen, Mar 04 '19 at 10:22
Definitely not line endings because when I start to resolve these conflicts they are indeed actual code changes. — lightsunray, Mar 04 '19 at 10:26

score 0 · Answer 1 · answered Dec 06 '21 at 10:55

Based on this question the problem is with git merge --squash master

git merge --squash produces a non-merge commit. Therefore, Git will not recognize that the commit you are merging from as the merge base. This leads to unwanted merge results.

As I can imagine the first squashed commit won't have any "fake" conflicts, but the second time when you merge the master into your branch with --squash git cannot locate the common ancestor, it would choose the initial commit on your dev_branch not the one that you've already merged with the squash.
So the conflicts based on the difference between the firstly merged commit on master and the latest commit on master.

Git merge conflicts on files that are NOT changed

1 Answers1