Confirmed users
839
edits
Platform/2013-05-07: Difference between revisions
→Roundtable
| Line 123: | Line 123: | ||
==Roundtable== | ==Roundtable== | ||
===Should we switch from hg to git?=== | |||
It's becoming more and more clear that the version control system of choice for open source development these days is git. The question is, should Mozilla engineering switch from Mercurial to Git?. As most people already know, lots of Mozilla hackers already use git for various types of work, and some of our significant projects also already use git (Gaia, Rust, Servo, etc). Lots of Gecko hackers also already use git for their work on mozilla-central, through various conversions from hg to git. | |||
One inevitable question that this raises is whether we're also switching to hosting Gecko development on Github, and the answer to that question is no. We've been in talks with Github, but we will not get the reliability guarantees we need nor the flexibility we need if we were to host Gecko development on Github, i.e. Github issues not being powerful enough, pull request data outside of our control, etc). | |||
As for switching the source control system from hg to git, here's some of the benefits: | |||
* Simplified on-boarding, people generally know git, but generally don't know hg. | |||
* We already mirror hg to git (in more than one way), git is already a necessary part of most of our lives and unifying our tools where we can is a good thing. | |||
* Branches! The ability to have "everything you want" in a single local repository (independently of how the repositories are hosted remotely). I.e. m-c, aurora, beta, release, user repositories, project branches and more as needed, no matter where the different branches are hosted. | |||
* No need for multiple local repositories, many working directories per repository. | |||
* Simplifies the path for better review tools and change workflows. | |||
* Opens the door for a pull-request like model for accepting changes. | |||
* Better merge algorithms, no more orphan patches that no longer apply cleanly. | |||
* Easier collaboration through shared branches. | |||
* Full history, all of hg and CVS! | |||
* OMG interactive rebase (squashing, removing, reordering, editing commits) | |||
* ZOMG git add --patch (selective change committing for splitting changes into multiple commits). | |||
* Works well with github, even though we're not switching to github as the ultimate source of truth. | |||
<br> | |||
Some of the known issues with doing this are: | |||
* New tool to learn for those who have not already needed to learn it. | |||
* Performance of git on windows is sub-optimal (we're already working on it). | |||
* Need to incorporate git into our windows build tools. | |||
* Lots of infrastructure work needed to make this switch. | |||
<br> | |||
The next step here is to take this discussion to the newsgroups to get | |||
feedback and make sure that everyone affected by this have a chance to | |||
weigh in before we decide whether we should make this switch. There's a | |||
lot of systems that depend on this outside of engineering. Identifying | |||
and switching all those systems from hg to git will be a significant | |||
amount of work that we'll need to measure and take into consideration | |||
here before we make any final decisions. | |||