Mozilla Firefox – Official GitHub repo

Original Article ↗ Hacker News Discussion ↗

Move from Mercurial to Git

  • Firefox’s canonical repo has moved from Mercurial to Git; GitHub is now the source of truth, with hg repos synced from Git instead of vice versa.
  • Previously both hg and git (via git-cinnabar) were supported; this change effectively begins the phase-out of hg.
  • Some lament the “git monoculture” and see this as a final blow to Mercurial, though others note hg is still maintained and used elsewhere.
  • Reported practical issues with hg included very slow initial clones compared to the unofficial git mirror.

Why GitHub and a New Org

  • Using mozilla-firefox instead of mozilla is attributed to GitHub’s org-level scoping: SSO, permissions, visibility, and policies are all per-org, so isolating Firefox can reduce risk and complexity.
  • GitHub’s limited hierarchy (essentially just org + repo) makes multiple orgs a common workaround; some contrast this with GitLab’s namespace model or GitHub Enterprise-level features.

Centralization, GitHub vs Alternatives

  • Strong disagreement over choosing GitHub instead of self-hosted Forgejo/Codeberg/GitLab.
  • Pro-GitHub arguments:
    • Contributor familiarity and discoverability (“be where the contributors are”).
    • Free, robust hosting for a very large repo; easier than running high-availability VCS infra yourself.
  • Anti-GitHub concerns:
    • Proprietary, Microsoft-owned, used for Copilot training; seen as misaligned with Mozilla’s open-web mission.
    • No IPv6, U.S. sanctions, and phone-number requirements block some potential contributors.
    • Risk of ecosystem lock-in around issues/PRs and social graphs, even though the code itself remains portable.
  • Codeberg is mentioned but criticized for uptime; GitLab.com’s FOSS program terms are seen as legally problematic for some.

How Firefox Uses GitHub

  • GitHub is currently used only for code and PR hosting; PRs are auto-closed with instructions to use existing workflows.
  • Bugs stay in Bugzilla; code review remains in Phabricator/Phorge with Lando; CI stays on TaskCluster.
  • Branch mapping: former mozilla-central → main; autoland remains as a staging branch merged into main when CI passes; various tree-named forks are used for large feature work.

Git, Workflow, and Tooling Debates

  • Long subthread on distributed vs centralized reality: git is still distributed technically, but the ecosystem is socially centralized on GitHub.
  • Suggestions to store issues/metadata inside git (e.g., git-bug, Radicle, git-notes) and to federate forges via ActivityPub; adoption remains low.
  • Extended arguments over pull requests vs email-based workflows vs Gerrit/Phabricator; PR UIs seen as both a huge usability win and a source of low-quality drive-by changes.
  • Many view Git’s UX as clunky compared to Mercurial or Fossil, but acknowledge GitHub significantly softened the learning curve.

Contributions, Gatekeeping, and UX

  • One camp argues GitHub lowers friction and is essential for attracting new contributors; another claims that people unwilling to learn non-GitHub workflows often produce low-value contributions.
  • Big debate over “gatekeeping”:
    • Some say raising process barriers filters spam and poorly thought-out PRs.
    • Others counter that any extra barrier discourages legitimate contributors and that maintainers should solve spam with tooling, not platform choice.
  • Contributors describe giving up on Firefox patches due to the complexity of combined GitHub + Phabricator flows before this migration.

Bug Tracking and Code Search

  • Many insist Bugzilla should remain, at least read-only, as a unique trove of historical web-compat reasoning.
  • GitHub Issues is widely viewed as feature-poor compared to Firefox’s customized Bugzilla instance.
  • For code navigation, some welcome GitHub’s search; others say Mozilla’s own Searchfox (and predecessors MXR/DXR) is significantly better for deep, cross-language navigation.