(Interrupting the shorter blog posts about features in the new vcs sync process, to talk a bit about discussions I've been having...)
We have three official git repos now:
- releases/gecko.git, which is partner-oriented, and our highest priority to keep sane (currently lives on git.m.o only),
- integration/gecko-dev, which is developer-oriented, and we want to offer a strong SLA for. It contains all release and inbound branches (currently lives on both github and git.m.o), and
- integration/gecko-projects, which contains mercurial repos without strict pre-commit hooks, and are periodically reset; RelEng reserves the right to reset the repo if these cause vcs-sync issues. (Currently on github only, due to the ease of resetting branches (or the entire repo).)
All three share the same SHAs for shared commits.
As for this recent, valid question: "Wow, that's a lot of complexity. Not worth just making a clean once-off break of renaming branches?" (In regards to how we name branches differently in gecko-dev and gecko.git.)
I originally wanted to name the branches after the trains, so gecko.git would be largely hands-off. If they want 1.2 code now, it's in aurora; if they want it after merge day, they'll need to pull from b2g26_v1_2. Easy enough. However, merge day would require careful communication and process timing across languages, companies, and timezones. All work is easier when it's someone else's, but on an objective level, communication and logistics can be more difficult than a technical solution. So now we point the v1.2 branch at trunk, then aurora, then b2g26_v1_2, and our partners can keep pointing at v1.2. And my vcs-sync configs are a little complex as a result of those branch names; a decent trade-off.
(So that's the why of the naming of things. I'm impressed you've read your way through nine of these (I assume). Insomnia?)