diff3 is not
- stable (formally, stability means that there exists a constant such that for small enough changes there is a guaranteed small merge)
The reason this would be useful is sometimes you kind of do need a merge to be large, and while a large and important PR is being reviewed someone may merge another large but less important PR that causes a delay for the first PR. Like if I was going to merge a big PR but then I saw that it would mess something up with higher priority, I'd already know to hold off without having to inquire or always know what everyone else is working on.
More software engineering research is good, I feel like we are lacking in that area. However, this was only for public code and analysis of private (company) code is not mentioned in the directions for future work. Would there be a way to extract information about conflicts and conflict resolution without giving away important parts of your code? I know that deobfuscation and retroengineering are whole fields, so I think companies wouldn't take the risk. But if there is a way to extract only the git information, maybe that would be possible.
In principle, it's good. In practice, I think we found it to be more trouble than it's worth... Engineers go on break / vacation / get hit by a bus too often with the locks held, and then there has to be a policy process to break the lock while that user still has outstanding changes that are now stale (in an entire environment that didn't reconcile "stale" code well because it was designed to prevent the need to merge code).
At our scale, this required us to have someone act as a full-time "repo guru," which was a brutally thankless job.