Hacker News Reader

I'd rather lock files, but be able to unlock them, to be able to coordinate with others and proactively reduce merge conflicts.

View on HN

The only way to make that simple is to centralize the version control system so that you can have a single arbiter of who has what locked. To add easy locking to Git, you'd have to turn it back into a non-distributed VCS.

I don't think I need to sell the value of DVCS over VCS, but what seems to get lost is that buys you a certain amount of essential complexity, expressed in the CAP theorem and its consequences.

We discussed this deeply on the Fossil forum: https://www.fossil-scm.org/forum/forumpost/2afc32b1ab

We came to no easy answers, because there aren't any. You only get a choice of which problems to accept.

I'm talking about purely advisory locks. Accessing a locked file would let you know who locked it, and if you unlock it, it would just notify them. So it's just a communications mechanism in addition to regular merges.

The alternate method is that locking a file marks you as an interested party to a merge, allowing you to review the correctness of a merge.

This would be purely to avoid changes being lost during merges.

Reply on news.ycombinator.com