From MozillaWiki
Jump to: navigation, search

Migrating from Hg to Git/Github

In discussing a migration from Mercurial (Hg) to Git, there are really two issues to address:

  1. migration from Hg to Git
  2. migration from Mozilla hosted to third party hosted (Github) repositories

This page summarizes the benefits, issues, and requirements for both #1 and #2. The material is flagged by role to allow people to easily view the information relevant to them.

There are three primary roles that make use of Mozilla's source code management (SCM) systems: developers [devs], release engineers [releng], and IT system admins [IT].

Migration from Hg to Git


  • Simplified onboarding for new contributors as Git is better known today than Hg [devs]
  • Git supports new workflows not supported by Hg [devs]
  • Git lets developers have a single repository (and multiple checkouts if so desired) for m-c, aurora, beta, etc, work [devs]
  • Better merging algorithm, fewer conflicts [devs]
  • Easier source code archeology, we'll have history since the dawn of time (i.e. all of Hg and CVS) [devs]
    • This is doable with Mercurial. We'd need a flag day. But we could do it if we wanted.
  • Git performs better than Hg (modulo in some operations on Windows, which we're working on) [devs]
  • Hg occasionally corrupts repositories (known bug, wontfix), no such known issues with Git [devs] [releng]
    • Modern versions of Mercurial don't corrupt repositories with nearly the same frequency as older versions. If you are referring to bug 737865, this is because Mozilla is hosting Mercurial over NFS, which is not recommended.
  • Mozilla currently makes use of Hg and Git, consolidation is easier for all devs [devs]
  • Better review tools (Gerrit) available for devs [devs]
    • Most review tools are built on the concept of *take a patch against a parent revision* and this concept works equally well with Mercurial and Git. ReviewBoard, Rietveld, and Phabricator all support Mercurial and Git.
  • Simplified debugging (no longer have to debug Hg) [releng] [IT]
    • You are just swapping Mercurial for Git.
  • Simplified management as only one SCM system [releng] [IT]
    • IT will still manage as not every project will switch to Git.


  • Overhead in having a large number of people learn new tools [devs]
  • Git for Windows performance (per above) compared to Hg [devs]
  • IT team has limited experience with Git at this point [IT]
  • git.m.o has had limited usage, need to review and stress test to ensure deployment can support scale [IT]
  • Cost to releng to update build and related tools [releng]


  • Update build tools (Windows tools specifically) to support Git [devs]
  • Must be able to create user repos as can do on Hg [devs]
  • Pushlog equivalent needs to be created for Git [devs] [releng]
  • Repository hooks [releng]
    • tree closure
    • approval required hook
    • try syntax
    • l10n change protector for aurora + beta (not yet implemented - see bug 859358)
  • Update for Nightly about:buildconfig to link to Git revision [releng]
  • Bugzilla must be updated to links to Git change sets, existing Hg links must not break [devs]
  • (links to changeset id) must be updated to support Git or an equivalent system put in place [devs] [releng]
  • crash-stats must be updated to support Git [devs]
  • l10n tooling must be updated to support Git
  • Will need to scale Git infrastructure (currently 2 machines) but should be able to reuse Hg machines [IT]
  • Replacements for third party tools currently in use by dev community

Moving from Mozilla hosted to third party (Github) hosted


  • Easier onboarding/discoverability for community [devs]
  • Nice change review system [devs]


  • Security of repo on hosted provider (can we trust our code to live there?) [releng] [IT]
  • Up-time of hosted repos (Mozilla up-time is very good, have had sync problems with GitHub repos) [releng]
  • Latency and failed pulls, some builds must pull from ~30 repos [releng]
  • Some teams (NSS, security) require internal hosting [devs] [IT]
  • Stability of repo / long term viability [devs] [releng] [IT]
  • Github issues cause confusion as work is tracked in Bugzilla (can issues be disabled?) [devs]
  • No pre-commit hooks, only post-commit hooks [releng]
    • no ability to block code commits, only react to bad commits
  • Limited ability to add new features


  • Must be able to back out changes without leaving history [releng]
  • Must have ability to duplicate current repository hooks (see requirements) functionality [releng]