GIT Pulling and merging generates Staged files and conflicts

Question

We decided to go with the GITFlow Workflow and we use Eclipse (w/ EGit) to do the development of our software.

Whenever someone makes a commit and pushes it to the remote repository and I do a subsequent pull (or fetch and merge) I receive the changes and I have encountered 2 problems:

All the files the other developer changed appear to me as unstaged files. For me this doesn't make sense since as I haven't done anything with the files they should just update themselves.
Often we get merge conflict with files that when we look there isn't any conflict at all, i.e. they don't have any differences other than Git have copy and pasted the contents of the file again above the file.

Can someone please explain, point me to some information or something that would clarify me these points or how I should proceed with them?

See http://stackoverflow.com/q/8227233/1700321 and http://stackoverflow.com/q/1510798/1700321. And use command line or SourceTree instead of egit. ;) — Aleksandr M, May 28 '14 at 08:51

score 1 · Accepted Answer · answered May 28 '14 at 09:37

The message of Aleksandr M clarify lots of thing : See stackoverflow.com/q/8227233/1700321 and stackoverflow.com/q/1510798/1700321. And use command line or SourceTree instead of egit. ;) – Aleksandr M 31 mins ago

I also warn you to verify twice what you are pushing :

Often we get merge conflict with files that when we look there isn't any conflict at all, i.e. they don't have any differences other than Git have copy and pasted the contents of the file again above the file.

Even if a file is not modify, his binary associated can be, if you push the two, then there will be conflict because they don't have the same hash code SHA1.

(Two object with the same SHA1 hash code are the same, it's use for identify the file, and two object with the same SHA1 hash code are never duplicated)

I don't think this is correct. A conflict arises if two people modify /the same line/ in children of a version then try to merge them together. They are equal in git's eyes so it cannot choose which change to keep. Having a different hash doesn't matter, you can have different hashes for the same file contents - e.g. you could modify a file, commit it, then modify it back and receive a different hash but the file's the same. then if you merged this in you definitely would not get a conflict as there are no differences. — scipilot, Apr 06 '15 at 02:52

score 1 · Answer 2 · edited May 23 '17 at 12:22

For your first point, I have just answered this same question here: https://stackoverflow.com/a/29463230/209288

Pull should do a fetch and a merge, which itself is a commit. Hence those changes by other people are applied to the files, staged, and then committed automatically. If something goes wrong with this automatic merge-commit (e.g. a conflict) then you will see the other people's changes left staged while you resolve the conflict.

For the second point - I have also seen "spurious" conflicts too and after many years have not come to a conclusion about some of them!

Sometimes it's whitespace: e.g. tabs/spaces or newlines being converted. Most Git GUIs have a "hide whitespace" option in the diff pane and so do the merge tools you use for conflict resolution. So sometimes what Git thinks is a conflict is handled more gracefully by the external merge tool, because you have relaxed the whitespace rules in its configuration. Sometimes what looks like no-change is a whitespace change when you turn off the ignore-whitespace options.

The only other conclusion I've come to is because the external merge tools could be better at merging than Git itself - or at least follow a slightly different algorithm. Therefore when git throws a conflict to an external tool, it might be able to solve it and shows you no conflict!

"they don't have any differences other than Git have copy and pasted the contents of the file again above the file."

I'm not sure I quite understand, if you are saying the file contents are duplicated inside itself, then you are probably seeing the conflict diff format. This would replicate the entire file if the line-endings differed.

If you're seeing this:

<<<<<<< HEAD
...entire file contents...
=======
...entire file contents...
>>>>>>> otherbranch

Then I'd almost guarantee your line endings have changed.

GIT Pulling and merging generates Staged files and conflicts

2 Answers2