Because having one as master and one as slave is exactly the problem i'm trying to solve here.
I want both to be master, so that users who are comfortable on both platforms are willing to make contributions to the codebase, so that any one service/system going down won't stop development, and so that as the "community" migrates around different platforms they can always find the full version of the software.
Recommending simplifying a process to the point that it no longer solves the problem it's trying to solve isn't helpful.
Sorry if my comments haven't been helpful. But I don't think the problem you're trying to solve is tractable. I'd be very interested to hear of a solution that doesn't rely on locking and is immune to conflicts.
You might fake it (and meet your stated goals) by maintaining a true master behind the scenes and syncing to two public slaves... (ie, forks you treat as peers, each with a "master" branch) but that still leaves neither of them truly "canonical" -- a designation of authority that would apply to the place where you'd resolve conflicts given simultaneous commits.
