I do not think the word "canonical" means what you think it means.

> accepted as being accurate and authoritative.

> synonyms: recognized, authoritative, authorized, accepted, sanctioned

That's what I meant for it to mean anyway...

In software the "authoritative" aspect of the definition is crucial.

How can two different endpoints both be authoritative? What happens if they differ?

Then people will be confused, which is why I'm exploring options to ensure they stay in-sync.

I'd recommend simply designating one as master, one as slave. Why try to appoint two captains of one ship?

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.

Sounds like that would be a pain having that kind of work done in two places.

Which is rather unfortunate for something that all revolves around git.