Is it though? Don't know anyone who likes merging or rebasing. Especially big merges. I don't know a solution. But I'm sure someone comes up with a significantly less painful way at some point.
I was using ClearCase for a few years and they had a really nice visual merge tool, but the complexity of the merge was great because they were so infrequent. I made a mistake and let someone find out I could merge and ended up getting sucked into these quarterly multi-day merge sessions that made me feel like a guild navigator stressing about breaking one of thousands of changes from 50 people over 90 days.
As for dealing with merge conflicts, it's called
- keep up to date with the branch your tracking
- merge frequently
- get on a call when you do have merge conflicts
- avoid having multiple people working in the same files simultaneously if possible
That sounds like a lot of words for "try really hard to avoid having merge conflicts, because they suck to deal with"
I've seen other systems essentially say, "Oops both versions modified this file... Good luck!" It didn't matter that the modifications were to very different parts of the file. I've never seen that in Git. Any merge conflict I've gotten in Git has been a true potential conflict, even if the resolution is straight-forward from my perspective.
A 3 way merge would have "original", "version a", "version b", and "version c", where "original" is the common ancestor of a, b and c. Mercurial disallows merges like this, but git supports them. I have no idea why git allows it.
But yes, older VCSs ignored the "original" concept, which meant diff tools could just pop up "a" and "b". Which is just a way worse idea than including the original as well.
If everyone develops from master branch and makes small incremental changes, no problem even if it's git.
If everyone develops from their own branches and goes off and does their own thing for a month, but those things are all in totally separate areas of the codebase, not as much of a problem either.
If everyone is developing in their own branches for a month, and they're working on overlapping things, and they aren't communicating? Then you get merge problems
But it's not really a merge problem, it's a communication problem. (And it's not git-only, you see merge problems even in perforce when people go dark for a long time and come back with a huge change that's got conflicts on 50% of the lines now)
The patch-centric model of Darcs and Pijul is insufficient. You also need to remember where patches came from. If rewriting a patch does not keep its provenance, you're also in for a world of hurt.
But even that is not sufficient. You need to have more context than even the patch-centric model gives you.