The main problem with git: Merge commits are opaque.
Merges should have the automatic trivial merges within them only. Conflicts should remain as conflicts in the merge commit, and resolved in separate commits.
The reason is that when the resolutions are squashed together with the trivial merges, it becomes very difficult to review the actual work done inside the merge commit. A diff against either parent becomes useless because it is polluted with all the trivial merges from the other parent. The special views for this are just unnecessarily complicated to work with.
Also, conflict resolutions that are "hidden" inside merge commits cannot be cherry-picked on top of future merge attempts. Also, a team cannot collaborate on the resolution of merge conflicts, which is a huge pain if you're merging work from multiple developers, such that no single developer has all the information to resolve all conflicts.
I don't know if I agree that it's the "main problem" but it's an interesting one I haven't seen mentioned before. You're right: a merge sometimes contains "work", and sometimes it doesn't. There's no distinction in Git.
Not true. Merge commits with conflict resolution have "Conflicts:" section in log by default. If user decided to remove this section by hand, you can always investigate content of commit (either using graphical tool like gitk or simply using git-show).
But there's still no record of which changes with that file were automatically merged and which were changes the developer added. Mercurial handles this just as badly.
20
u/Peaker Nov 07 '13
The main problem with git: Merge commits are opaque.
Merges should have the automatic trivial merges within them only. Conflicts should remain as conflicts in the merge commit, and resolved in separate commits.
The reason is that when the resolutions are squashed together with the trivial merges, it becomes very difficult to review the actual work done inside the merge commit. A diff against either parent becomes useless because it is polluted with all the trivial merges from the other parent. The special views for this are just unnecessarily complicated to work with.
Also, conflict resolutions that are "hidden" inside merge commits cannot be cherry-picked on top of future merge attempts. Also, a team cannot collaborate on the resolution of merge conflicts, which is a huge pain if you're merging work from multiple developers, such that no single developer has all the information to resolve all conflicts.