Git marking identical "both added" files as a conflict during a merge

user_1430705 0
Viewed 41

I'm trying to merge a branch from a remote repo into ours (this is done periodically). However, I've ran into problems.

What I got is over 3000 conflicts (which is absurd, we edited less than 100 files since the last merge), most of them being "both added", but completely identical. Why can't git resolve this automatically? I've run tortoisemerge as merge tool and I have to manually mark each of the files as resolved, one by one. I've checked, the files in conflict have the same hash.

There are also several files where the conflit is in EoL symbol, which shouldn't be happening since I merge.renormalize has been set to true. I've also tried using both

git merge -s recursive -Xignore-space-at-eol

and

git merge master -s recursive -X renormalize

But with the same result, conflicts when EoL doesn't match.

Any ideas as to what might be wrong here?

EDIT: It seems that it is a permission conflict, the execute bit to be exact. However, I've set core.fileMode to false, so it shouldn't mark them as different.

git-merge git
1 Answers

Git currently always considers a "both added" situation a conflict, even if the two added files are identical.

If you dislike this, you could work on Git itself. It does seem reasonable to ask that "both added identically" be considered a non-conflict. Touching the merge strategy code is nontrivial, though.

In the meantime, it's easy to add a post-merge step that handles these for you. Use:

git ls-files --stage

(perhaps from a shell script or Python program; if using Python, consider adding -z and splitting the binary stream at b'\0' bytes in case of "difficult" file names). Try this by hand first and look at the output. Note how each conflicted file has a nonzero stage number—that's the one-digit number after the hash ID—and many of your conflicts will have stage 2 and stage 3 files but no stage 1 version of that file, e.g.:

100644 f3266cd66e7ffc6821a2f425832f4f2ceb697e59 2       .gitignore
100644 f3266cd66e7ffc6821a2f425832f4f2ceb697e59 3       .gitignore

The lack of a stage-1 file means that this occurred as an add/add conflict. The fact that the two hash IDs are identical means that the two file contents are identical. You may therefore reduce this file to a non-conflicted one by extracting either version—they are identical—and then git add-ing that version of the file; git add will take care of fixing the staging numbers. Alternatively you can invoke git update-index directly, which is a bit more efficient since you won't need to fuss with working tree files at all, but you'll probably still want to fix the working tree file to remove the conflict markers.

Having settled such add/add conflicts away, you'll be down to just the real conflicts, which need real work.

user_12564520
Related