[lars]

A middle ground could be nice: An IDE extension that notifies you when something you're writing will conflict in the future, should you and your coworker both commit and push what you've typed out. It would allow you to sort that out immediately, or at least plan ahead, rather than being surprised by a large merge conflict n days down the road.

[jerf]

Agreed; that sounds like it could be potentially useful. If you've got something with a central server already in the model, up to and including something like github or something, it doesn't even sound that hard to check that on a per-push basis. A bit of trickiness around what constitutes a "live" branch, but that seems amenable to heuristics.

[hinkley]

There's no reason BitBucket, GitLab, and GitHub couldn't scan all of the unmerged commits on pushed branches to look for impending merge conflicts. BitBucket at least does once you start a PR. They could be more aggressive about that without changing any underlying algorithms.

The main difference would be that the PR check only compares with master, and you'd want to compare all branches. But a low-constant-factor test for collisions would make that cheap enough (conflicts can only occur for commits that contain the same file names, which is an O(mlogm) set intersection test of short text strings)

[boleary-gl]

GitLab team-member here.

GitLab also detects if there is a conflict on a merge request as things change and will notify the user