Firefox Moves to GitHub
159 comments
·May 13, 2025bandrami
SCdF
I get what you're saying, but tbf hosting on github doesn't (yet!) box you out of just moving back to that system. It's still just git. It's still distributed, in the sense that if github goes down you could still generate patches and email them around, and then push back to github when it's back.
Everything surrounding code: issues, CICD, etc, is obviously another story. But it's not a story that is answered by distributed git either. (though I would love a good issue tracking system that is done entirely inside git)
nextaccountic
Unfortunately the project is not just code. It also has issues, PRs and other stuff. Github has two kinds of lock in, a) your stuff is there and if you move elsewhere you probably will wipe your issues etc (huge loss of institutional knowledge), and b) there is a network effect because everyone has a github account and people are used to just hop on a repository and file an issue (rather than being greeted by a log in page), cross-reference issues between repositories (hard to make work if repos aren't in the same site, unless both sites use some interop thing like activitypub which github will never use), etc
> Everything surrounding code: issues, CICD, etc, is obviously another story. But it's not a story that is answered by distributed git either. (though I would love a good issue tracking system that is done entirely inside git)
There is https://github.com/git-bug/git-bug - would love if people started o use it, even in a read only way: use github issues normally, but also have a bot that saves all coments to git-bug, so that i can read issues without an internet connection. Then, at a later date, make it so that people that make issues on git-bug also gets the issue posted on github, making a two way bridge.
Then, optionally, at a later stage when almost everyone migrated to git-bug, make the github issues a read only mirror of the git-bug issues. Probably not worth it: you lose drive-by comments from newcomers (that already have a github account but probably never heard of git-bug), raising the friction to report bugs
SCdF
> Unfortunately the project is not just code.
The literal project we are discussing is just code. It's literally just code. It doesn't have issues, PRs are disabled as much as they can be (by a GitHub action that automatically closes all PRs with a note that code should be submitted elsewhere), and all "other stuff" is disabled.
sshine
> if github goes down you could still generate patches and email them around, and then push back to github when it's back.
You could, but generally people can’t. They learn a set of narrow workflows and never explore beyond. GitHub use translates into GitLab use, but not into general git use workout a central repository.
> Everything surrounding code: issues, CICD, etc, is obviously another story. But it's not a story that is answered by distributed git either. (though I would love a good issue tracking system that is done entirely inside git)
Radicle offers one. CLI-based, too.
flohofwoe
> They learn a set of narrow workflows and never explore beyond.
And tbh, that's how it should be for a version control system. Before git with its byzantine workflows and a thousand ways to do the same thing, version control (e.g. svn) was a thing that's just humming along invisibly in the background, something that you never had to 'learn' or even think about, much like the filesystem.
I don't need to know how a filesystem works internally to be able to use it.
And having a centralized store and history helps a lot to keep a version control system conceptually simple.
laserbeam
> You could, but generally people can’t. They learn a set of narrow workflows and never explore beyond.
The point is you CAN. Joe can in theory do it, and Steve can make an alternative piece of software to do it for Joe. In most other centralized places (like social media), you CANNOT. Joe cannot take his data off of Facebook and interact with it outside of the platform or move it to another platform.
lucianbr
People could learn, if there was suddenly a need. Just like they learned the narrow workflows they use now.
arp242
"I only accept patches and bug reports over email" is just as much of a narrow set of workflows as "I only accept patches and bug reports through PRs".
account-5
This is why I like fossil, it comes with most of the stuff I use built in, and you can deploy it as a website too. Use it for all of my personal projects and used it extensively for coursework at university.
rablackburn
>> I would love a good issue tracking system that is done entirely inside git
You might like git-bug:
sublinear
IIRC Phabricator stored most of it's metadata in git-notes. In theory we could have been making tools compatible with such a format all this time.
Sander_Marechal
Gitlab is working on using ActivityPub for interoperability between instances. See: https://handbook.gitlab.com/handbook/engineering/architectur...
dijit
> Everything surrounding code: issues, CICD, etc, is obviously another story. But it's not a story that is answered by distributed git either. (though I would love a good issue tracking system that is done entirely inside git)
Embrace, Extend..
(largely this is unfair, as plain git leaves much to be desired- but you can’t deny that the things surrounding git on github are very sticky).
wordofx
Build a bridge and…
frizlab
Like fossil?
kaichanvong
while --it-is possible seeing how fossil confuses, for the Github conversation, it's not really in the same category, conversation, some clever happenings happening within fossil-scm, however, it's not really the same as the problem design-led github solves given people saying downtimes; sure, git, github; however how people using github, different–similar, git, however, github.
However, were you to say liken-able (slang keywords: comparative something else--) of, "fossil with git-github", then again: no.
Good call were the conversation (comments, almost interchangeable at-times haha!) being, everyone use git for Firefox, something kinda wild-topic!
phire
People have forgotten just how bad centralised version control was in 2005.
If you weren't connected to the internet, you couldn't do a thing. You couldn't checkout. You couldn't commit. You could create branches. The only thing on your computer was whatever you checked out last time you were connected to the server.
People talk about SVN, but it wasn't that common in 2005. None of the project hosting platforms (like SourceForge) supported SVN, they were all still offering CVS. If you wanted to use SVN, you had to set it up on your own server. (From memory, google code was the first to offer SVN project hosting in mid-2006). Not that SVN was much better than CVS. It was more polished, but shared all the same workflow flaws.
Before Git (and friends), nothing like pull-requests existed. If you wanted to collaborate with someone else, you either gave them an account on your CVS/SVN server (and then they could create a branch and commit their code), or they sent you patch files over email.
The informal email pull requests of git were an improvement... though you still needed to put your git repo somewhere public. Github and its web-based pull requests were absolutely genius. Click a button, fork the project, branch, hack, commit, push, and then create a formal "pull request". It was nothing like centralised project management systems before it. A complete breath of fresh air.
IshKebab
Plenty of people use Codeberg and Gitlab. And it's still distributed - I don't need to lock files and ask coworkers if I can work on them.
Maybe if Git had native support for PRs and issues this wouldn't have happened. (And yes I'm aware of git send-email etc.)
mmis1000
I think it would be great if git have some kind of soft lock by default (like attach a text on some file without make it into actual commit). It could probably make peoples' live easier when you and teamates need to communicate what files you are changing thus reduce the chance of conflict.
mashlol
FWIW git lfs does have support for locking files.
spookie
Yeah, especially binaries.
qwertox
In Codeberg, how does one even search for files containing a given string? Probably the #1 thing I do on GitHub is searching for files in a project containing a given string.
sph
Given how terrible GitHub search in files is, what I usually do is clone the repo and run ripgrep.
jimbob45
That exact exercise filled a quarter of my workday today.
mhh__
Git should have issue support or something like it as a convention but pull requests are an abomination that we are stuck with. No thank you.
captn3m0
Not Git, but several forges are working towards an ActivityOub based federation format for these: https://f3.forgefriends.org/
eru
Git was invented with pull requests in mind. It's just that they were originally meant to be sent via email, not on the web.
kace91
Can you expand on that? I’m probably younger but I can’t imagine a more comfortable way to review code.
snickerbockers
ironically hardly anybody outside of the linux kernel community uses it the way it was intended lol.
Didn't all this start with Linus getting into a spat with the bitkeeper dev involving some sort of punitive measure as a response to somebody making a reverse-engineered FOSS client? I don't remember the details and I'm sure I have at least half of them wrong, but that's easily one of the most disastrous decisions in the history of the software-business right up there with valve turning down minecraft and EA refusing to make sports games for the SEGA dreamcast (that last one isn't as well known but it led to SEGA launching the 2k sports brand to which outlasted the dreamcast and eventually got sold to a different company but otherwise still exists today and is still kicking EA's ass on basketball games).
eru
That's how git started.
But there were already quite a handful of other distributed version control systems around by the time git showed up.
So if Linus hadn't written git, perhaps we would be using darcs these days. And then we'd be debating whether people are using darcs the way it was intended. Or bazaar or monotone or mercurial etc.
I don't think what the original authors of any one tool intended matters very much, when there were multiple implementations of the idea around.
vintermann
> Didn't all this start with Linus getting into a spat with the bitkeeper dev
It's a joke that the bitkeeper dev has two revision control named after him, Mercurial and Git.
bitwize
I've heard the one that says much like Linux, Git is named after Linus himself.
midnightclubbed
EA not making sports games for Dreamcast wasn’t a bad decision for EA. It cost Sega a huge amount of money to produce and license their own sports games exclusively for Dreamcast, not having EA sports was a huge blow.
And while NBA 2k destroyed NBA Live it took until 2009 for that to start happening (long after Sega ownership), mainly down to sliding standards in EA’s NBA Live titles and eventually some disastrous EA launches.
rowanG077
I don't see how EA creating their biggest rival is anything but a bad decision for them. Had they licenses they would have a monopoly and probably millions of more sales.
formerly_proven
It would've made sense to change many defaults in git for "normal users" ages ago (git 2?) instead of keeping the kernel-workflow defaults.
NexRebular
It really is a tragedy that git monoculture is winning over Mercurial, Fossil and other better designed alternatives. Don't even have a nice github-like service for Mercurial anymore as Bitbucket decided to give up.
ratatoskrt
To be fair, Git itself is a bit of a pain, and GitHub's main achievement is/was to make it somewhat bearable.
casenmgreen
I regard the Git docs as being fully equal to scientific Wikipedia articles.
Everything is fully and completely explained, in terms which mean nothing.
eru
I find both Wikipedia and Git docs typically more useful than this. Much more.
(They ain't perfect, of course.)
spookie
To be fair, most of the its difficulty is realized when you're stuck with a teammate rewriting history. Who, much like anyone anyone doing the same, hasn't bothered reading a book explaining things.
jamienicol
That problem is solved by preventing forced pushes. Rewriting history locally is encouraged.
baq
If you don't rewrite history in git, I don't want to bisect in your repos.
If you push rewritten history to master, you're a git.
Conclusion: learn your tools.
tester756
No, git's CLI is terrible mess.
mmis1000
In some sense, git is actually like advanced zip versioning system. A commit is literally just a snapshot of code base except it tell you what is the previous version of this version.
Also, git store the files in a smarter way so file size won't explode like zip versioning.
eru
> A commit is literally just a snapshot of code base except it tell you what is the previous version of this version.
Or previous versions. Plural. Yes.
Well, that's one half of git. The other half is tooling to work with the snapshots and their history, eg to perform merges.
johannes1234321
The reason is that it is more than code. Managing identity is hard and for many projects besides having a source of truth for the repository you also need some degree of project management (bug tracking)
And: Even though source of truth is centralized for many projects in GitHub, git still benefits from being distributed: It's the basis for "forks" on VithUb and for the way people develop. Ja jung the clone locally and committing locally and preparing the change set for review. In the CVS/SVN days one had to commit to the ce teal branch way sooner and more direct.
eru
Yes, in git you get the benefit of fine-grained version control while you are still exploring.
Then later on for the PR, you can sanitise the whole thing for review.
In the bad old days, you only got the latter. (Unless you manually set up an unrelated repository for the former yourself.)
ghosty141
I don't get this. Git is still distributed, even if the "main" repo is on github, everybody still has a local copy. You are confusing project management (which github effectively does) and git. Git is still git, github is just a project management tool with git integration.
In the Linux kernel the project management is done via email (which is also just a centralized webserver in the end), so whats the problem?
miyuru
The problem is lot of Dev tools has centralized on GitHub, so much so that we cannot use IPv6 only servers for development because GitHub does not support IPv6.
From what I use composer and brew relies on GitHub to work.
jgraham
(I work at Mozilla, but not on the VCS tooling, or this transition)
To give a bit of additional context here, since the link doesn't have any:
The Firefox code has indeed recently moved from having its canonical home on mercurial at hg.mozilla.org to GitHub. This only affects the code; bugzilla is still being used for issue tracking, phabricator for code review and landing, and our taskcluster system for CI.
In the short term the mercurial servers still exist, and are synced from GitHub. That allows automated systems to transfer to the git backend over time rather than all at once. Mercurial is also still being used for the "try" repository (where you push to run CI on WIP patches), although it's increasingly behind an abstraction layer; that will also migrate later.
For people familiar with the old repos, "mozilla-central" is mapped onto the more standard branch name "main", and "autoland" is a branch called "autoland".
It's also true that it's been possible to contribute to Firefox exclusively using git for a long time, although you had to install the "git cinnabar" extension. The choice between the learning hg and using git+extension was a it of an impediment for many new contributors, who most often knew git and not mercurial. Now that choice is no longer necessary. Glandium, who wrote git cinnabar, wrote extensively at the time this migration was first announced about the history of VCS at Mozilla, and gave a little more context on the reasons for the migration [1].
So in the short term the differences from the point of view of contributors are minimal: using stock git is now the default and expected workflow, but apart from that not much else has changed. There may or may not eventually be support for GitHub-based workflows (i.e. PRs) but that is explicitly not part of this change.
On the backend, once the migration is complete, Mozilla will spend less time hosting its own VCS infrastructure, which turns out to be a significant challenge at the scale, performance and availability needed for such a large project.
floriangosse
I think it's actually an understandable strategical move from Mozilla. They might loose some income from Google and probably have to cut the staff. But to keep the development of Firefox running they want to involve more people from the community and GitHub is the tool that brings most visibility on the market right now and is known by many developers. So the hurdle getting involved is much lower.
I think you can dislike the general move to a service like GitHub instead of GitLab (or something else). But I think we all benefit from the fact that Firefox's development continues and that we have a competing engine on the market.
mritzmann
What is the source of “Firefox Moves to GitHub”? It could be a mirror, just like Linux also has an mirror on GitHub.
xrdev
My thoughts as well, even more so after seeing the only GitHub Workflow they have is actually for closing Pull Requests with a default response:
https://github.com/mozilla-firefox/firefox/blob/main/.github...
Kuinox
It's good that they fixed one of the major tech debt for contributing to firefox. When I tried a few years ago, mercurial took multiple hours to clone, and I already had to use the unofficial git support in order to have things working before the end of the day.
Their docs was also a mess back then and made me recompile everything even if it wasnt needed.
antalis
Firefox Mobile (Fenix) had just moved to Mozilla's Mercurial mozilla-central repository after using GitHub including for issues. https://github.com/mozilla-mobile/firefox-android/wiki#upcom...
Now, both the desktop and the mobile version will be on Github, and the "issues" will stay on Bugzilla.
This will take advantage of both GitHub's good search and source browsing and Git's familiar system.
As a former Firefox and Thunderbird contributor, I have to say that I used local search instead of trying to find something on the mozilla-central website.
Of course, when you're actively developing software, you search inside your IDE, but allowing to find things easily on the website makes it more welcoming for potential new contributors.
adrian17
> I have to say that I used local search instead of trying to find something on the mozilla-central website.
On the contrary, I find searchfox to be the best code navigation tool I used. It has nice cross-language navigation features (like jumping from .webidl interface definition to c++ implementation), it has always-on blame (with more features too) and despite that it's really fast and feels extremely lightweight compared to GitHub interface. I really wish I had this with more projects, and I'll be sad if it ever dies.
mlenz
Great to see, but I wonder what lead to the decision of creating a new org instead of using github.com/mozilla
moontear
Without knowing their reason, there are a few things tied to the org where multiple orgs make sense. If you do SSO for example you tie the org to a SSO provider, you can’t tie „just a few users“ to the SSO provider (afaik). The Firefox repo may have totally different authentication / users than the main Mozilla repo.
temp0826
They have many orgs-
sofixa
GitHub are terrible at this, because you can't have levels other than Org and Repository. And many things (SSO, visibility rules, common configs) are on the org level.
Unfortunately often the cleaner option is to create a separate org, which is a pain to use (e.g. you log in to each separately, even if they share the same SSO, PATs have to be authorised on each one separately, etc).
In Gitlab, you would have had one instance or org for Mozilla, and a namespace for Firefox, another one for other stuff, etc.
captn3m0
There is an “Enterprise” level above the org, but that obviously needs an Enterprise account. It lets you manage some policies across multiple orgs, including membership.
sofixa
But it still requires multiple orgs, and the UX is still poor.
It's like AWS accounts vs GCP projects. Yeah, there are ways around the organisational limitations, but the UX is still leaky.
thrdbndndn
Correct me if I'm wrong, IIRC the previous "master" branch is `mozilla-central`.
Now it has "main" and "autoland", what are they? Which one is the equivalent of mozilla-central before?
chme
Not a firefox dev, but pretty sure its 'main'
The "new" git default branch name is 'main' and 'autoland' existed before next to 'mozilla-central' and is the one where commits usually appear first.
jamienicol
I am a Firefox developer, and you're spot on. Previously there were separate hg repos for central, beta, release. I think ESRs too. And autoland. Now they're all branches in the same repo, and central is renamed main.
Commits land in autoland and get backed out if they cause test failures. That's merged to main ~twice per day when CI is happy
tgsovlerkhgsel
On one hand, centralization at a commercial provider isn't great.
On the other hand, the plethora of different self-hosted platforms with limited feature sets is a huge pain. Just finding the repo is often a frustrating exercise, and then trying to view, or worse, search the code without checking it out is often even more frustrating or straight out impossible.
smallnix
I wish I could search on GitHub without logging in
hedayet
I wish that too, and I’ve always wanted to offer features like this in everything I build.
But it’s a lot of work to prevent abuse, especially for resource intensive features when supporting unsigned-in use cases.
nicce
They used to have 64 core 32 machine cluster just for search. You may want to reduce unnecessary search. https://github.blog/engineering/the-technology-behind-github...
CorrectHorseBat
So they moved from hg to git? Or is this just an official mirror
shit_game
firefox development has been moved from mercurial to git since early november of 2023
swiftcoder
Interesting that their issues are blamed on "dual SCM", not on Mercurial itself. I guess just the weight of contributors expecting Git as the default is sinking the big Mercurial projects these days.
Kuinox
I tried to contribute a few years ago. The mercurial clone was taking multiple hours. They already had an non official git, which took 15 minutes to clone.
dgoldstein0
Isn't mercurial abandonware? Or maybe I'm just remembering that gitlab dropped support. If it's not dead yet seems to be getting there
IshKebab
They supported Git and Hg until now. This means they are dropping Hg support.
octocop
Nice, I was just checking yesterday to find the source code of firefox. Even if it is only a mirror it's a nice step to make it more available I think.
mentalgear
Would have been great if they used an European alternative ( like Codeberg ).
selectnull
Mozilla is US organization, why would they care to?
neilv
As for European specifically, maybe the commenter was talking about data protection laws. If not, maybe (in many European countries at the moment) less national or business background of ruthlessness.
I was thinking something different: I wonder whether Mozilla considered GitLab or Codeberg, which are the other two I know that are popular with open source projects that don't trust GitHub since it sold out to Microsoft.
(FWIW, Microsoft has been relatively gentle or subtle with GitHub, for whatever reason. Though presumably MS will backstab eventually. And you can debate whether that's already started, such as with pushing "AI" that launders open source software copyrights, and offering to indemnify users for violations. But I'd guess that a project would be pragmatically fine at least near term going with GitHub, though they're not setting a great example.)
pparanoidd
lol codeberg is down right now, bad timing
Pretty cool that Linus Torvalds invented a completely distributed version control system and 20 years later we all use it to store our code in a single place.