Hacker News Reader

Comment by hinkley | Hacker News Reader

One of the reasons we compartmentalize code is so that people can work on unrelated features without tripping over each other at every turn.

The bits where they don't interact also don't conflict. The bits where they do, look a lot more like collaborative editing.

They're also the spots where merges usually go wrong.

View on HN

I've been on systems where multiple developers were trying to develop on the same system at once. I've also seen teams trying to do it systematically. It scales basically to two developers, sitting across from each other. Three, again, physically colocated, on a good day. Even if they're working on completely separate tasks, you hit "compile" and it's a complete mystery what's going to happen. It's not even stable if you do nothing and just hit "compile" again.

Beyond that it's insane. You do not want that in your version control system, as something built in, working all the time, across your entire team. It would be a massive anti-feature that would nuke your product.

Again, anyone thinking this sounds like a totally awesome idea, I strongly encourage you to try out the simple version, availablbe right now, of just "five or six people editing the same source code checkout" right now, before betting a start up on it. I guarantee a complete lack of desire to productize the result if you try it for a week or two.

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.

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.

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)

GitLab team-member here.

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

Reply on news.ycombinator.com