FlaShG
Three-Way Merge
As far as I can tell, GitMerge only does a two-way merge, and so can only tell you if any given value differs between your version and their version. This means that a lot of things show up as conflicts that should be trivial to resolve automatically (e.g. I changed I value and they didn't). It would be difficult to implement, but would make GitMerge massively more useful and would mean that it provides functionality that even UniMerge can't.
I read a thing or two about three way merges and I'm not sure when and how they would be useful. If they changed a value and you didn't, maybe it is because you added a GameObject that solves the underlying problem in another way. But since those thoughts apply to three way merging in general, I started implementing a thing or two for this idea. In b94c823, there is a method GetBase that checks out the common ancestor of head and merge_head the way that GetTheirs checks out their version.
I guess that it would be counterproductive to just automatically resolve and hide conflicts that don't have a change on one branch, but maybe automerge them and display them in yellow, like the MergeActionNewGameObject.
There's a really good GDC talk given by one of the guys working on BitSquid talking about exactly this and explaining why three-way merging assets is so good, but its a members-only video and my account is through my employer so I can't lend it out to you. I can do a longer write up if you're interested, but what it comes down to is that when you're doing a three-way merge for stuff like assets, the only case that actually results in a conflict is when two people change the same value on the same asset. Everything else has a sane automatic merge, which greatly reduces the difficulty of merging work on large scenes.
A recent example of this in my case is the incident that prompted #42, i.e. my level designer rearranged most of the objects in the level and when I went to merge every single one of them came up as a conflict. Since I didn't change any of them on my end, only she did, they weren't "conflicting", the reasonable thing to do would be to accept her changes. Adding and removing objects complicates things a bit, but almost all cases can be handled reasonably automatically.
So it wouldn't be counterproductive to automatically resolve these "conflicts", just the opposite since it saves a bunch of time confirming changes you (or someone else) already made. And even if you're uncomfortable about taking control out of the hands of the developer (trust me, I am too), it would be easy to provide a configuration file for selecting the default merge behavior and allow the developer to opt-in to automatic merges.