SCM/HGtoGit

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

Benefits

• Simplified onboarding for new contributors as Git is better known today than Hg [devs]
• Git supports new workflows not supported by Hg [devs]
• Mozilla currently makes use of Hg and Git, consolidation is easier for all devs [devs]
• Better review tools (Gerrit) available for devs [devs]
• Simplified debugging (no longer have to debug Hg) [releng] [IT]
• Simplified management as only one SCM system [releng] [IT]

Issues

• Overhead in having a large number of people learn new tools [devs]
• There is a question about whether the Git for Windows tools perform as well as the Hg tools [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]

Requirements

• Update build tools (Windows tools specifically) to support Git [devs]
  • jlebar's tools https://github.com/jlebar/moz-git-tools
• 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]
• tbpl.mozilla.org (links to changeset id) must be updated to support Git or an equivalent system put in place [devs] [releng]
• 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
  • Dave Townsend's HG Change Feed (source)

Moving from Mozilla hosted to third party (Github) hosted

Benefits

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

Issues

• 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

Requirements

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

References

• Value of GitHub etherpad