For a long time Firefox Desktop development has supported both Mercurial and Git users. This dual SCM requirement places a significant burden on teams which are already stretched thin in parts. We have made the decision to move Firefox development to Git.
- We will continue to use Bugzilla, moz-phab, Phabricator, and Lando
- Although we’ll be hosting the repository on GitHub, our contribution workflow will remain unchanged and we will not be accepting Pull Requests at this time
- We’re still working through the planning stages, but we’re expecting at least six months before the migration begins
APPROACH
In order to deliver gains into the hands of our engineers as early as possible, the work will be split into two components: developer-facing first, followed by piecemeal migration of backend infrastructure.
Phase One - Developer Facing
We’ll switch the primary repository from Mercurial to Git, at the same time removing support for Mercurial on developers’ workstations. At this point you’ll need to use Git locally, and will continue to use moz-phab to submit patches for review.
All changes will land on the Git repository, which will be unidirectionally synchronised into our existing Mercurial infrastructure.
Phase Two - Infrastructure
Respective teams will work on migrating infrastructure that sits atop Mercurial to Git. This will happen in an incremental manner rather than all at once.
By the end of this phase we will have completely removed support of Mercurial from our infrastructure.
Right, but squashed commits don’t scale for large PRs. You could argue that large PRs should be avoided, but sometimes they make sense. And in the case where you do have a large PR, a commit by commit review makes a lot of sense to keep your history clean.
Large features that are relatively isolated from the rest of the codebase make perfect sense to do in a different branch before merging it in - you don’t merge in half broken code. Squashing a large feature into one commit gets rid of any useful history that branch may have had.
I agree, and GitHub allows choosing how to merge each PR individually if you need to do something different for a specific PR. Large PRs like that are at most 1% of our total PRs, and we review those more per-commit and use a merge commit instead of a squash. By default we optimize for the other 99%.