This is really interesting and I would love to know what the code in question was responsible for.
Requiring that work on it be done single-threaded like this suggests that some other part of the overall process broke down somewhere - the developers/automated tests/continuous integration server couldn't catch merge conflicts? Code reviews weren't done and made visible to everyone else on changes to this special code?
Not necessarily. It could be a particularly tricky and critical piece of code that they want to ensure nobody is "auto-merging" into oblivion.
By putting a mutex on it, you are forced to re-evaluate the state when you obtain the lock. You can't sneak in a change in front of somebody else's change, requiring them to re-evaluate (or, worse, merge and hope).
If it was required for modules all over, it would be broken process. For a single module, I can understand it.
Good question - though I don't think it's a problem of broken process, but an absence of processes like you listed above. That's when these types of "solutions" are devised/used.
>1. Sometimes the best process is old fashioned communication between people with common sense.
I most wholeheartedly agree. Git, or a Source Control Shingle cannot replace effective communication. In fact, a solving a merge conflict is much more painful than a quick discussion.
Requiring that work on it be done single-threaded like this suggests that some other part of the overall process broke down somewhere - the developers/automated tests/continuous integration server couldn't catch merge conflicts? Code reviews weren't done and made visible to everyone else on changes to this special code?