Mozilla Firefox – Official GitHub repo

https://github.com/mozilla-firefox/firefox

by thefilmore • 1 year ago

855 460 1 year ago

github.com

mlenz• 1 year ago

Great to see, but I wonder what lead to the decision of creating a new org instead of using github.com/mozilla

temp0826• 1 year ago

They have many orgs-

https://wiki.mozilla.org/GitHub#other_github

moontear• 1 year ago

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.

pornel2• 1 year ago

The GitHub SSO is annoying. I can't even view public issues if I'm logged in to GitHub, but haven't recently re-authenticated with SSO.

GitHub also has a lot of features and authentication scopes tied to the whole org, which is pretty risky for an org as large as Mozilla.

sofixa2• 1 year ago

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.

captn3m02• 1 year ago

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.

baobun7• 1 year ago

Presumably a case of Conways.

https://en.m.wikipedia.org/wiki/Conways_Law

CorrectHorseBat• 1 year ago

So they moved from hg to git? Or is this just an official mirror

shit_game• 1 year ago

firefox development has been moved from mercurial to git since early november of 2023

https://www.phoronix.com/news/Firefox-Going-Git

swiftcoder3• 1 year ago

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.

IshKebab10• 1 year ago

They supported Git and Hg until now. This means they are dropping Hg support.

sfink3• 1 year ago

Not yet at least. Currently both are still supported, it's just that the core repo is now in git syncing to hg rather than the other way around.

But I think hg support is going away. We hg enthusiasts at Mozilla are mostly fleeing to Jujutsu.

reddalo• 1 year ago

Why GitHub? If they truly cared about open-source they would've chosen something else, such as a self-hosted Forgejo [1], or its most common public instance Codeberg [2].

[1] https://forgejo.org/ [2] https://codeberg.org/

AStonesThrow2• 1 year ago

If they truly cared about open-source

Perhaps Microsoft offered to pick up the tab that Google has been paying, but is now imperiled, or at least lend some sort of financial support, and Firefox cares more about paying their bills than open source

mzi• 1 year ago

Codeberg unfortunately have an abysmal uptime track record.

danpalmer• 1 year ago

I would argue that part of "truly caring" about open-source is being where the contributors and community are. That's probably a large part of the move to GitHub, and neither of these other options would achieve that. As much as one can say "git is distributed, the server doesn't matter", the centre of the community very much does matter, and for better or worse that's currently Github.

arccy• 1 year ago

If you maintain a popular project, you'll quickly find that github prs are a massive source of spam and low quality prs with people that don't even bother to follow up.

Bad PRs all around, with just a constant stream of drive by "why no merge?!?!?!" comments.

Tepix• 1 year ago

We need to work on decentralisation of git forges, making it less relevant where a project is hosted by offering cross-instance collaboration and discoverability.

gsich• 1 year ago

Probably only for visibility. Or MS is in the process of sponsoring them.

aucisson_masque2• 1 year ago

MS is in the process of sponsoring them.

Think you might be on something, with the incoming end of Google cash flow, Firefox may be in discussion with bing and that could be part of the agreement, use Microsoft server.

pndy• 1 year ago

Considering image backlash they had over last year with: acquiring ad tech company created by former meta people, which in turn lead to introducing so-called "privacy preserving attribution" feature for ads tracking, changing ToS terms regarding data collection, firing CPO who was diagnosed with cancer. Then I do believe these all little changes are PR stunts with an attempt to regain trust of users who strongly criticised Mozilla in last year and earlier.

They should restructure instead, hire people who actually want to work on software and not use corporation and foundation around it as platform for their... peculiar "endeavours". But I doubt that's gonna happen - flow of Google cash and from all those naive people who think supporting Mozilla directly contributes to Firefox is too good it seems. But then it's understandable they do this - money from Google tap can get twisted.

protocolture• 1 year ago

If they truly cared about open source they would have hosted their own git on a run down pentium 2 in a nerds basement, never washed, and spent most of their time complaining online.

freddie_mercury• 1 year ago

To assert that an organisation doesn't "truly" care about open source simply because they've chosen a tool that isn't is ridiculous.

Even before this Mozilla almost certainly used hundreds of closed source tools, including things like Slack, Excel, Anaplan, Workday, etc.

Lightkey• 1 year ago

Using proprietary software in-house for management is one thing, forcing outside contributors to use them, another. That is why they went out of their way to avoid Slack when the time came to leave IRC behind and they chose Matrix instead.

rurban• 1 year ago

I maintain some project on all forges in parallel, even savannah. Savannah is even the default. But 99% of all reports and contributions are on the github mirror, 1% on savannah, 0% on gitlab and 0% on codeberg. Nobody cares about those islands.

issues are stored in git bug and automatically synced. Github is the only viable option, but you can keep the others as mirrors when github chooses to strike you.

bandrami• 1 year ago

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.

moralestapia3• 1 year ago

Care to explain?

aucisson_masque2• 1 year ago

Linus Torvalds invented git, which is what's used by GitHub and others like gitlab.

joha42702• 1 year ago

If GitHub went down, how much would it impact the open source world?

Sure, there would be local copies everywhere, but for a distribution version control system, it's pretty centralized at GitHub

IshKebab10• 1 year ago

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.)

mmis10003• 1 year ago

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.

mhh__6• 1 year ago

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.

qwertox2• 1 year ago

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.

ratatoskrt• 1 year ago

To be fair, Git itself is a bit of a pain, and GitHub's main achievement is/was to make it somewhat bearable.

casenmgreen2• 1 year ago

I regard the Git docs as being fully equal to scientific Wikipedia articles.

Everything is fully and completely explained, in terms which mean nothing.

mmis10003• 1 year ago

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.

spookie4• 1 year ago

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.

SCdF4• 1 year ago

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)

littlestymaar2• 1 year ago

Everything surrounding code: issues, CICD, etc, is obviously another story

That's what Github is though, it's not about the code itself it's about all your project management being on Github, and once you move it, moving out isn't realistic.

sublinear2• 1 year ago

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.

sshine• 1 year ago

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.

account-52• 1 year ago

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.

frizlab2• 1 year ago

Like fossil?

dijit2• 1 year ago

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).

rablackburn2• 1 year ago

> I would love a good issue tracking system that is done entirely inside git

You might like git-bug:

https://github.com/git-bug/git-bug

Sander_Marechal• 1 year ago

Gitlab is working on using ActivityPub for interoperability between instances. See: https://handbook.gitlab.com/handbook/engineering/architectur...

nextaccountic2• 1 year ago

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

nicoburns2• 1 year ago

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.

You can also quite easily set up a temporary remote (this can be as simple a directory on an SSH server), or if you're on the same local network, pull and push directly from each others' local copies.

vasco• 1 year ago

Most people have it at least in two places if they work alone and in many places if they work with others. Having a consistent central UI doesn't take away from the distributed part, while adding a bunch of goodies.

baq8• 1 year ago

When you clone a repo you store it on your computer, too. Don’t confuse version control with CI servers/bug trackers/software forges.

sorbusherra• 1 year ago

which is also owned by microsoft, that uses github data to train large language model. So, after decades of trying to kill linux and sabotage it, they finally figured out how to own it.

masfoobar2• 1 year ago

As a Free software supporter, its just a matter of time before we lose out on our freedoms. Honestly, once Linus retires I do think Linux will continue to thrive with a good team but Linux, the kernel, will either have to adapt to current times (whatever that can be in the future) or something else will replace it and, likely, some AI aspect on top.

It wont be free software and, likely, it will be Microsoft.

littlestymaar2• 1 year ago

Moving to git is understandable (Mozilla was using mercurial) but Github, really?

It's not like the hairy C++ code base of Firefox will suddenly become less scary and attract more open source developers simply because it's moving to Github.

snickerbockers2• 1 year ago

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).

formerly_proven• 1 year ago

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.

vintermann2• 1 year ago

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.

midnightclubbed• 1 year ago

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.

eru12• 1 year ago

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.

lmm• 1 year ago

Turns out the important part wasn't the distributed-ness at all (unless you count being able to work offline). Many such cases.

globular-toast2• 1 year ago

Oh it is, but I think people forget what the distributed model gets you. It isn't just about having a completely decentralised workflow. When you clone a repo you have everything you need to keep working on that project. You have your own copy of all the branches which you are free to do whatever you want with. This is what makes it fast. Every clone has a brand new master branch and you never needed to ask anyone or get agreement to get your own branch to work on. Commits on your branch will never interfere with anyone else's work. You don't need to lock files and complete your work as quickly as possible. You can do as many commits as you like, a hundred in a day is not unheard of, because it's your branch. Previously people would commit once a day at most and sometimes not even until the end of the week, which is just unthinkable to a git user. A git clone is your own personal repo which allows you to use version control before you even share anything with anyone.

OtomotO3• 1 year ago

I find this comment really interesting, because NONE of my clients in the last 10 years of (self-) employment had even a single codebase on GitHub.

I am contributing to a few open source projects on GitHub here and there though.

voidspark2• 1 year ago

GitHub is not Git.

Git is by far the most widely used VCS. The majority of code hosting services use it.

Barrin92• 1 year ago

It's no more surprising than the fact that we invented distributed protocols to talk online and yet people use gmail or Facebook rather than sending data over the wire themselves.

People who are very insistent on distributed solutions never seem to understand that the economic, social and organizational reasons for division of labor, hierarchy and centralization didn't suddenly go away.

johannes1234321• 1 year ago

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.

eru12• 1 year ago

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.)

ahoka• 1 year ago

Git wouldn't be mainstream without GitHub though.

dijit2• 1 year ago

It might feel like that now, but in 2011 github was just one of a bunch of code forges and at the time they were all similar in quality.

Gitorious was chosen for the meego/maemo team for example.

novaRom• 1 year ago

Linus Torvalds is one of those people whos impact on the world is significant even if he was not driven by financial initiative. It’s crazy how much one person can change things just by solving their own problems really well.

tester7562• 1 year ago

Why should we care about what Linus invented?

ghosty141• 1 year ago

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• 1 year ago

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.

https://github.com/orgs/community/discussions/10539

phire3• 1 year ago

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.

guappa4• 1 year ago

A patch over email is how git works too!

chgs• 1 year ago

Pull requests aren’t part of git. They are a feature of one implementation.

lupusreal4• 1 year ago

I am sure Sourceforge supported subversion by 2007 or 2008, I had a project there then. When was it added?

TZubiri• 1 year ago

pretty cool that we have a distributed version control system but people still complain that the distributed version control system is not itself hosted on a public distributed version control system like a ouroubouros of transparency so transparent that you can't even see the thing and you lose it because you don't know where it is and you lose yourself in a maze of infinitely branching dependency tree of self hosted bug trackers and federated account systems so that you can keep track of your bug reports and compile the bug tracker from scratch and all of a sudden you are building linux and you want to report a linux bug, but you need to send an email so you build an HTTP server but you don't have a C compiler yet so you download the latest C source code, but you don't have a C compiler to compile it, so you just make a github account and learn to compromise on your ideals welcome to adulthood.

csomar• 1 year ago

distributed # decentralized. The point of distributed is to keep a copy of your own. The point of decentralized is to not have a central point of authority.

contravariant• 1 year ago

I'm fine with it as long as ssh still works.

NexRebular2• 1 year ago

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.

1wd• 1 year ago

heptapod is GitLab with Mercurial support.

int_19h7• 1 year ago

This happened mostly because the benefits of those other tools over git are so marginal that they don't provide a strong motivation to pick them over git unless everything else is equal. With GitHub in the picture, everything else is not equal, and so...

BeetleB• 1 year ago

I had been chronically depressed with Mercurial's decline, but now at least jj gives me hope for sanity:

https://github.com/jj-vcs/jj

m-schuetz• 1 year ago

I have no use for a distributed source control system. I want my stuff consolidated at one place.

starspangled• 1 year ago

Really? You rm -rf your working trees each evening before you finish, and git clone them from github in the morning? :)

I store my code in a completely distributed fashion, often in several places on different local devices (laptop, build server, backup, etc) not to mention on remote systems. I use github and gitlab for backup and distribution purposes, as well as alternative ways people can share code with me (other than sending patch emails), and other people use git to get and collaborate on my work.

distributed version control system doesn't mean distributed storage magically happens. You still need to store your code on storage you trust at some level. The distributed in DVCS means that collaboration and change management is distributed. All version control operations can be performed on your own copy of a tree with no other involvement. Person A can collaborate with person B, then person B can collaborate with person C without person A being in the loop, etc.

ignoramous• 1 year ago

That gives too much credit to git and way too less to Preston-Werner, Wanstrath, Hyett, & Chacon, and many others: https://www.youtube-nocookie.com/embed/mGTpU5XUAA8

Double_a_92• 1 year ago

How is it a single place if every dev has a full copy of the repository? Also unless it's some software that each user customizes and builds for themselves, you still need some kind of way to tell which is the official version.

cookiengineer• 1 year ago

To be fair: Linus didn't predict how painful email is in 2025. Self hosting email is a useless attempt if 99% of your emails land in spam anyways, and only spammer emails land in your inbox because they pay for azure or google business accounts.

The general issue that git has is making them interact with each other, I would love for git to get distributed issues, and a nice client UI that is actually graphical and usable by non-terminal users.

There were some attempts to make this distributed and discoverable via similar seed architectures like a DHT. For example, radicle comes to mind.

But staying in sync with hundreds of remotes and hundreds of branches is generally not what git is good at. All UIs aren't made for this.

I'm pointing this out because I am still trying to build a UI for this [1] which turned out to be much more painful than expected initially.

[1] https://github.com/cookiengineer/git-evac

PurpleRamen• 1 year ago

The code is still distributed. Every git clone usually creates a new, self-preserving copy (if we ignore some special flags). The problem is those features, which GitHub is offering outside of code. And I guess the irony is that GitHubs success is probably the reason nobody is adding them to git itself. Like add some subfolders into the repo for issues, wiki, discussions, etc. and have a UI for handling them all, easy. Instead, we have forges&tools supporting separate repos with flavours of widely used formats, making everything more complicated...

przemo_li• 1 year ago

That's wrong hot take.

GH have forks. Those are distributed repos. You can also sync to GitLab and similar, you can front it with the likes of Gerrit, integrate some code review UIs that actually clone code, etc.

You can exercise distributed nature of git with GitHub quite well.

IshKebab10• 1 year ago

Not for PRs or issues though which are arguably the biggest reasons to use GitHub. Still this is definitely an improvement.

baq8• 1 year ago

Which is fascinating since both suck. Gerrit (replace with whatever if you please) is a much better change submission experience and basically anything else is a better bug tracker.

The killer feature is collocation of features to a single forge, combined with a generous free tier it’s the windows xp of the ecosystem: everybody has it, everybody knows it, almost nobody knows anything else.

matkv• 1 year ago

So is this now just a mirror? I'm not sure what the point of moving to GitHub was then.

IshKebab10• 1 year ago

It's the primary repo rather than a mirror, but yeah I agree it they don't get most of the benefits. Moving issues and PRs is probably an enormous effort so I get why they aren't doing it all at once.

elric6• 1 year ago

GitHub's issue tracker is easily the worst issue tracker I've ever used. It's at the same time incredibly limited in features, but somehow hard to navigate.

As for PRs: I'm sure Mozilla welcome contributions, but accepting GitHub PRs is going to be a recipe for thousands of low-value drive-by commits, which will require a lot of triage.

IshKebab10• 1 year ago

Count yourself lucky you haven't had to use Jira! Or bugzilla for that matter.

I agree it is rather basic but I don't see how it's hard to navigate.

accepting GitHub PRs is going to be a recipe for thousands of low-value drive-by commits, which will require a lot of triage.

I don't think that really happens based on what I've seen of other huge projects on GitHub.

thrdbndndn2• 1 year ago

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• 1 year ago

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.

jamienicol2• 1 year ago

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

mhh__6• 1 year ago

Inevitable. GitHub is a good platform in need of some proper dev workflows (pull requests are atrocious, branches footguns, yml driven CI is a noose) but they've obviously won.

jopsen• 1 year ago

I don't Firefox is moving to Github Actions anytime soon. I was pretty involved with the TaskCluster setup years ago, and it still seems to be running a bunch of CI things.

mozilla-central has a LOT of tests -- each push burns a lot of compute hours.

sfink3• 1 year ago

Yes. All CI is remaining in TaskCluster. Bugs are remaining in bugzilla, not GH issues. Code review is remaining in Phabricator (pre-Phorge fork), pushing in Lando (a custom layer).

Some associated projects are using more GitHub stuff.

DennisL123• 1 year ago

A BUILD.md could be useful.

mdaniel4• 1 year ago

the readme is literally 21 lines long, and about 25% of them are blank lines, with the 2nd URL pointing to "how to contribute" and that link has a dedicated "how to build and run" https://firefox-source-docs.mozilla.org/contributing/contrib...

The bad news is that their build system is extremely hand-rolled, and so if it works for you, count yourself lucky, because when it doesn't work you're in for 4 hours of python hell

floriangosse• 1 year ago

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.

fhd23• 1 year ago

In my experience, most contributors who are deterred from contributing because they can't use GitHub aren't particularly valuable contributors. I'm sure there's exceptions, but I haven't seen any for non-trivial open source projects I've been involved in. I might even argue that it could be good to have a slightly higher bar to deter low quality one time contributors.

berkes6• 1 year ago

You just showed the poster-child of gatekeeping that is harming Open Source.

Every contributor is valuable, it's in the name, the definition of "contribute".

Any bar to entry is bad, it certainly never is the solution to a different problem (not being able to manage all contributions). If anything, in the longer run, it will only make it worse.

Now, to be clear, while I do think GitHub is currently the "solution" to lower barriers, allow more people to contribute and as such improve your Open Source Project, the fact this is so, is a different and other problem - there isn't any good alternative to Github (with broad definitions of "good") why is that and what can we do to fix that, if at all?

lpln34525• 1 year ago

Contribution isn’t driven by a desire for rewards, but by goodwill. Friction only gets in the way. If the friction is worth it, fine - but what exactly is being lost by moving the repository to GitHub?

rendaw• 1 year ago

How can you judge the quality of people who don't contribute? They don't contribute, so what's there to judge?

arp2429• 1 year ago

I spent quite some time writing a patch for FreeBSD and Linux a few months ago, including getting to grips with their contribution process.

Both patches have been ignored thus far. That's okay, I understand limited resources etc. etc. Will they ever be merged? I don't know. Maybe not.

I'm okay with all of this, it's not a complaint. It's how open source works sometimes. But it also means all that time I spent figuring out the contribution process has been a waste. Time I could have spent on more/other patches.

So yeah, there's that.

It's certainly true that making the bar higher will reduce low-quality contributions, because it will reduce ALL contributions.

(aside: FreeBSD does accept patches over GitHub, but it also somewhat discourages that and the last time I did that it also took a long time for it to get reviewed, although not as long as now)

Philpax2• 1 year ago

I can say that I've chosen not to bother when submitting a fix requires me to stray away from GitHub, and doubly so when it doesn't use a PR/MR workflow. There are only so many hours in the day, and I don't have the patience to deal with unconventional workflows when there are other things I could be doing with my time.

For projects that I'd be interested in being a long-term contributor to, this is obviously different, but you don't become a long-term contributor without first dealing with the short-term, and if you make that experience a pain, I'm unlikely to stick around.

A big part of this is the friction in signing up; I hope federated forges become more of a thing, and I can carry my identity around and start using alternate forges without having to store yet another password in my password manager.

nicman232• 1 year ago

"gatekeeping good"

no.

7bit2• 1 year ago

So, you're saying that because they don't know to use A they are likely to also don't know enough to contribute to B?

Being a good coder has absolutely no correlation to being good at using Mercurial.

arichard123• 1 year ago

Hang on. If they are deterred, then by definition they are not valuable contributors. They have not contributed. If they have contributed, they were not deterred.

pornel2• 1 year ago

The barriers may keep out low effort submissions*, but they also keep out contributors whose time is too valuable to waste on installing and configuring a bespoke setup based on some possibly outdated wiki.

* contributors need to start somewhere, so even broken PRs can lead to having a valuable contributor if you're able to guide them.

Aachen2• 1 year ago

Am I understanding you correctly that using github instead of a more obscure system where you might need to register a fresh account and find where the buttons are etc. raises the bar for contributions and so it's good to use github?

Somehow I think you're holding the difficulty scale backwards!

madeofpalk• 1 year ago

I absolutely gave up on trying to contribute a patch to Firefox because the combination of both gh and phabricator was too much for me.

I struggled to understand how the two interacted with each other, and I didn't know how to 'update my branch/pr' and I eventually just gave up.

kgwxd• 1 year ago

Anyone that couldn't overcome those "hurdles" shouldn't even be filing bug reports, let alone modifying code.

noobermin4• 1 year ago

I get moving to Github being a change but I'd imagine the real story is the move from mercurial to git, although I'd guess the the social considerations might have influenced the technical decisions.

lolinder• 1 year ago

With GitLab specifically as an alternative: GitLab made it very clear a few years ago that they weren't particularly interested in hosting large-scale free projects when they introduced the Open Source Program as the only path to using GitLab for FOSS. I've heard over and over again that this process is painful and not worth the effort, and it has a bunch of extra requirements that would likely be dealbreakers for Mozilla [0]:

* "the Open Source Project does not, and does not seek to, generate profit from the sale or licensing of the Open Source Software to which the Open Source Project relates, or the sale of any services related to such Open Source Software;"

* "The Open Source Project agrees not to (nor to authorize any third party to): ... (b) modify or create any derivative works of the GitLab Software ... (d) copy ... the GitLab Software"

That last part is especially problematic for everyone: in order to use GitLab.com for a FOSS project you have to renounce your right to modify (or authorize others to modify) or to copy the FOSS version of GitLab. This might have just been lawyers adding boilerplate without thinking it through, but that in itself is evidence of a major problem at GitLab.

So, GitLab is out. Aside from GitLab Mozilla could have chosen maybe Codeberg, but with the entire point being to remove barriers to new contributors it makes sense to go with the option that almost all such possible contributors are already on.

[0] https://handbook.gitlab.com/handbook/legal/opensource-agreem...

WhyNotHugo• 1 year ago

The move to GitHub is quite disappointing. For a foundation wanting to push an open Internet and open source, moving to a proprietary forge which stands against all its core values reflects very poorly on the entire community.

mentalgear• 1 year ago

Would have been great if they used an European alternative ( like Codeberg ).

selectnull6• 1 year ago

Mozilla is US organization, why would they care to?

neilv2• 1 year ago

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• 1 year ago

lol codeberg is down right now, bad timing

berkes6• 1 year ago

I've used Codeberg for some projects and while their work and services are impressive and their progress steady and good, it's really not a proper alternative to Github for many use-cases.

"It depends", as always, but codeberg lacks features (that your use-case may not need, or may require), uptime/performance (that may be crucial or inconsequential to your use-case), familiarity (that may deter devs), integration (that may be time-consuming to build yourself or be unnessecary for your case) etc etc.

antalis2• 1 year ago

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• 1 year ago

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.

antalis2• 1 year ago

Searchfox didn't exist back then, "there [was] only xul", I mean MXR of course.

Then MXR got replaced by DXR, itself replaced in 2020 by Searchfox (introduced in 2016).

https://discourse.mozilla.org/t/decommission-dxr/69475

https://billmccloskey.wordpress.com/2016/06/07/searchfox/

baobun7• 1 year ago

This will take advantage of both GitHub's good search and source browsing and Git's familiar system.

The source browsing has detoriated severely relatively recently IME, to the point where i can't be called "good" anymore.

It now loads asynchronously (requiring js) and lazily, randomly breaks on shaky connections and in-page search is broken.

The recent issues/PRs revamp is also a pretty major step back. Try searching in PRs with all uBlock Origin lists enabled.

tgsovlerkhgsel• 1 year ago

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• 1 year ago

I wish I could search on GitHub without logging in

nicce2• 1 year ago

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...

hedayet• 1 year ago

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.

elric6• 1 year ago

Just finding the repo is often a frustrating exercise

Surely most open source projects have a link to their source code? Whether it's github, gitlab, sourcehut, or anything else?

LegionMammal9782• 1 year ago

Many GNU and GNU-adjacent projects will happily list their release tarballs, but make it annoyingly difficult to find the underlying repos that most of them use. Usually the link is squirreled away somewhere in the "contributing" guidelines.

rvz• 1 year ago

Centralizing everything to GitHub really isn't a good idea given their frequent incidents every week.

petepete3• 1 year ago

I wonder how long it'll take for my PR which entirely removes the built in Pocket integration will take to be dismissed.

petepete3• 1 year ago

Thankfully it won't be necessary!

mritzmann• 1 year ago

What is the source of “Firefox Moves to GitHub”? It could be a mirror, just like Linux also has an mirror on GitHub.

https://github.com/torvalds/linux

// EDIT: Source: https://news.ycombinator.com/item?id=43970574

xrdev• 1 year ago

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...

sakjur• 1 year ago

It’s interesting how pull requests remain the only tab (apart from code) that cannot be disabled by the repo owners.

I get it from GitHub’s perspective, it’s a nudge to get people to accept the core premise of ”social coding” and encouraging user pressure for mirrored projects to accept GitHub as a contribution entrypoint. I’m impressed by their successes and would attribute some of that to forced socialization practices such as not allowing PRs to be disabled. I’ve grown to dislike it and become disillusioned by GitHub over the course of a long time, but I’m in awe of how well it has worked for them.

octocop• 1 year ago

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.

Kuinox2• 1 year ago

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.

jgraham4• 1 year ago

(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.

[1] https://glandium.org/blog/?p=4346

iamcreasy• 1 year ago

Thanks for the added context.

If I may - what were the significant scale challenges for self hosted solution?

bayindirh5• 1 year ago

I guess it's the CI/CD infrastructure. Pipeline and time requirement grows exponentially as the code supports more operating systems and configurations.

I used a GitLab + GitLab Runner (docker) pipeline for my Ph.D. project which did some verification after every push (since the code was scientific), and even that took 10 minutes to complete even if it was pretty basic. Debian's some packages need more than three hours in their own CI/CD pipeline.

Something like Mozilla Firefox, which is tested against regressions, performance, etc. (see https://www.arewefastyet.com) needs serious infrastructure and compute time to build in n different configurations (stable / testing / nightly + all the operating systems it supports) and then test at that scale. This needs essentially a server farm, to complete in reasonable time.

An infrastructure of that size needs at least two competent people to keep it connected to all relevant cogs and running at full performance, too.

So yes, it's a significant effort.

jgraham4• 1 year ago

Again, I can only comment from the perspective of a user; I haven't worked on the VCS infrastructure.

The obvious generic challenges are availability and security: Firefox has contributors around the globe and if the VCS server goes down then it's hard to get work done (yes, you can work locally, but you can't land patches or ship fixes to users). Firefox is also a pretty high value target, and an attacker with access to the VCS server would be a problem.

To be clear I'm not claiming that there were specific problems related to these things; just that they represent challenges that Mozilla has to deal with when self hosting.

The other obvious problem at scale is performance. With a large repo both read and write performance are concerns. Cloning the repo is the first step that new contributors need to take, and if that's slow then it can be a dealbreaker for many people, especially on less reliable internet. Out hg backend was using replication to help with this [1], but you can see from the link how much complexity that adds.

Firefox has enough contributors that write contention also becomes a problem; for example pushing to the "try" repo (to run local patches through CI) often ended up taking tens of minutes waiting for a lock. This was (recently) mostly hidden from end users by pushing patches through a custom "lando" system that asynchronously queues the actual VCS push rather than blocking the user locally, but that's more of a mitigation than a real solution (lando is still required with the GitHub backend because it becomes the places where custom VCS rules which previously lived directly in the hg server, but which don't map onto GitHub features, are enforced).

[1] https://mozilla-version-control-tools.readthedocs.io/en/late...

PaulDavisThe1st• 1 year ago

If you provide an http based front end to git, one of the significant (newish) challenges of self hosting is dealing with AI bots/scrapers.

lupusreal4• 1 year ago

This only affects the code; bugzilla is still being used for issue tracking

Grim.

The best reason to be using github at all is to maximize the portion of your users who are comfortable submitting bug reports, as they already have an account and are familiar with how the platform works (due to network effects.) Projects which host code on github but chose not to take bug reports there are effectively gate keeping bug submission, by asking their users to jump through the hoops of finding the site, signing up for it, and learning to use a new interface. I've done this before, with Bugzilla and Firefox, to submit a bug report for an accessibility bug on MacOS and it was a pain in the ass that I put off for a long time before becoming annoyed enough to go through the process. (End result: the bug was confirmed but never fixed..)

dspillett3• 1 year ago

Moving the existing data over might not be a quick and easy task, so takes planning. Perhaps they intend to move over but didn't want to do everything in one go. Making many changes at the same time can be much more risky than a staged approach.

are effectively gate keeping bug submission

Of course this could be a benefit… Have you seen the quality of bug reports coming from some people, even other devs? :-)

matkoniecz6• 1 year ago

I suspect that Firefox is not bottlenecked on number of bug reports they got.

jgraham4• 1 year ago

Gecko and Firefox have been using Bugzilla for more than 25 years at this point. There's a lot of internal workflows, tooling and processes that are really dependent on the specific functionality in Bugzilla. I think it would be an extremely high risk project to try and replace Bugzilla with GitHub issues.

That said, there are also other teams and projects who do use GitHub for issue tracking. However the closer to Firefox/Gecko you are the harder this gets. For example it's hard to cross-reference GitHub issues with Bugzilla issues, or vice versa. I've seen people try to build two-way sync between GitHub and Bugzilla, but there are quite considerable technical challenges in trying to make that kind of cross-system replication work well.

However your point that GitHub makes issue submission easier for people who aren't deeply embedded in the project is a good one. I'm directly involved with webcompat.com, which aims to collect reports of broken sites from end users. It's using a GitHub issue tracker as the backend; allowing developers to directly report through GitHub, and a web-form frontend so that people without even a GitHub account can still submit reports (as you can imagine quite some effort is required here to ensure that it's not overwhelmed by spam). So finding ways to enable users to report issues is something we care about.

However, even in the webcompat.com case where collecting issues from people outside the project is the most important concern, we've taken to moving confirmed reports into bugzilla, so that they can be cross-referenced with the corresponding platform bugs, more easily used as inputs to prioritization, etc. That single source of truth for all bugs turns out to be very useful for process reasons as well as technical ones.

So — (again) without being any kind of decision maker here — I think it's very unlikely that Firefox will move entirely to GitHub issues in the foreseeable future; it's just too challenging given the history and requirements. Having some kind of one-way sync from GitHub to Bugzilla seems like a more tractable approach from an engineering point of view, but even there it's likely that there are non-trivial costs and tradeoffs involved.

AlienRobot• 1 year ago

If you really want bug reports just make it a single form without the need to create an account. Github, Gitlab, etc., is a wall for 99% of web browser users.

dblohm74• 1 year ago

I understand what you're saying, but still:

GitHub issues is terrible compared to Mozilla's Bugzilla instance. It's not even close.

emigre• 1 year ago

Thanks for the context. IMHO I don't think Mozilla should have decided to move to a closed-source platform owned by Microsoft.

fguerraz• 1 year ago

Thanks to the decentralised nature of git, this should matter only moderately.

LtdJorge2• 1 year ago

Will GeckoView and Mozilla Android Components be on GitHub too?

rstat1• 1 year ago

I was gonna say they already were and had been for a while, but apparently a few weeks ago they moved back in to the main Firefox repo.

Which means I guess they're back on Github now.

thayne• 1 year ago

Given that Phabricator has been discontinued, are there any plans to replace that with something else? Phorge perhaps?

Operyl• 1 year ago

Both forks coexist and pull fixes from each other.

kristel100• 1 year ago

Honestly surprised it took this long. For a project that depends so much on community contribution, being on GitHub just lowers the barrier for new devs. Curious to see if this revives contribution velocity.

berkes6• 1 year ago

In the very least, it will open up FTEs that can now work on what makes Mozilla projects unique, rather than on building and maintaining generic fundamentals.

It's a pet-peeve and personal frustration of mine. "Do one thing and do that well" is also often forgotten in this part of Open Source projects. You are building a free alternative to slack? spend every hour on building the free alternative to slack, not on selfhosting your Gitlab, operating your CI-CD worker-clusters or debugging your wiki-servers.

roschdal• 1 year ago

Firefox moves to GitHub. Now someone better make a fork to make a proper web browser, small, fast, lean and without bloat and surveillance.

edelbitter• 1 year ago

So no IPv6 in the foreseeable future?

baobun7• 1 year ago

It really is a bummer that we still can't clone over IPv6 in 2025. So annoying to have to set up (and pay for) IPv4 egress proxy on so many build systems and servers just because of this.

https://github.com/orgs/community/discussions/10539

bingemaker• 1 year ago

They already have an org github.com/mozilla. Why didn't they move ff source there?

nikolayasdf123• 1 year ago

nice, GitHub is defacto place to keep and release code

cubefox• 1 year ago

I assume this is now one of the largest (lines of code) projects on GitHub.

mdaniel4• 1 year ago

I'd bet https://github.com/brave/brave-core would top FF, since it's both chromium _and_ Brave's extra bits

mintplant• 1 year ago

Why is the mozilla-firefox org full of forks of the main repo named after trees?

https://github.com/mozilla-firefox

dblohm74• 1 year ago

I haven't worked for Mozilla since 2021, but back then the branches named after trees were used as feature branches for large projects, at least until those projects were in a good enough state to cleanly merge back into trunk without breaking CI.

kbrosnan• 1 year ago

They are used for large scale landings or when a project needs to track trunk development but will churn a lot.

https://wiki.mozilla.org/ReleaseEngineering/DisposableProjec...

sylware• 1 year ago

Bad Move.

github.com broke noscript/basic (x)html interop for most if not all core functions (which were working before). The issue system was broken not that long time ago.

And one of the projects which should worry about, even enforce, such interop, moving to microsoft github...

The internet world is a wild toxic beast.

zajio1am• 1 year ago

To me it seems absurd that such organization like Mozilla uses third-party hosting like GitHub instead of something self-hosted or at least running under their own name. I understand that one-person projects use GitHub, but forcing contributors to make account with third-party service seems contributor-hostile.

garganzol2• 1 year ago

If it is an open source project then why not. This gives some visibility and welcoming openness to the project where everyone can contribute.

nolok• 1 year ago

I hope the bugzilla stay there even if only read only. There is a lot of historical data in there, especially for the web which was built as a "ad-hoc" platform, many times when you wonder why does X the answer can only be found in bugzilla (which will explain that some random website that used to be major but doesn't even exists anymore, did something for some browser that used to be major but doesn't even exists anymore).

fergie• 1 year ago

Bugzilla was really good, and in retrospect decades ahead of its time. There is probably no self hosted bug tracker that comes close (or it there?)

sfink3• 1 year ago

Bugzilla is still the bug tracker for Firefox. I know if no plans to change that. (Github issues are not being used for the Firefox repo.)

upcoming-sesame2• 1 year ago

Why did they choose the mozilla-firefox org as opposed to the already existing mozilla org ?

https://github.com/mozilla

alpha_trion• 1 year ago

That's an excellent question

heftig• 1 year ago

Different access rules, I guess. Or maybe they wanted some separation from the existing org so the custom automation has no chance of doing collateral damage.

upcoming-sesame2• 1 year ago

Why did they use mozilla-firefox org name instead of the already existing https://github.com/mozilla one ?

noobermin4• 1 year ago

I guess the dream is dead. Even in open source, we have consolidation with no real hard monetary markets involved.

EDIT: skimming these comments, I like how none of the top comments are talking about the bigger story here which is the move away from mercurial to git and instead everyone is focusing on github itself. This has essentially sealed hg away to obscurity forever. Do people not realise git is a program that runs on your computer and github is just a service that uses git? May be this is an old man gripe at this point but I'm surprised at the lack of technical discussion around this.

dzaima3• 1 year ago

This is far from the first project to move from hg to git; many people probably just generally expect that to happen upon any source code management change for anything still using mercurial, which has already been effectively dead for most people for years.

noobermin4• 1 year ago

My point doesn't really dispute that hg is dead "for most people" whatever that means, it's just that what the hg people could point to in the past was firefox, but now they've lost that example. Now, we can surely say it is dead.

To be frank, I know of no other major project that used hg. In fact, I think firefox was how I learned about it in the first place many years ago.

garganzol2• 1 year ago

I cannot imagine moving to Git from Mercurial. Git looks clunky from my perspective. Yes, it works too, but working with Git is a usability torture, sorry but it is true. I like some Git features better though, but not most of them.

static_motion• 1 year ago

I'm a pretty young developer and git is the only VCS I'm familiar with, and even though it has its quirks I find it quite powerful and a perfectly adequate tool for the job. In what way is Mercurial better?

noobermin4• 1 year ago

My honest opinion is that I hate that git won, it's too complicated for no benefit with complexity I personally will never leverage as a scientist who doesn't work in large teams.

I use it for visibility and ease, that's all. Otherwise I personally dislike it.

elmer007• 1 year ago

Star Wars reference in a comment: https://github.com/mozilla-firefox/firefox/blob/917c73cfe1a5...

Fun to get a glimpse into someone's thought process while they were working.

thund• 1 year ago

Hate seeing how repos are so polluted by dot-files and dot-folders. I wish tools and SDKs converged into a single dot-folder, so that we could look at repos without seeing everything everywhere

metalliqaz• 1 year ago

What are 'pine', 'maple', 'holly', etc?

hanlonsrazor• 1 year ago

Internal nomenclature for feature branches.

InTheArena• 1 year ago

as a side note - I love the new bookmark tabs feature. About time :-)

kidsil• 1 year ago

First commit: https://github.com/mozilla-firefox/firefox/commit/c4cc52826a...

Hard to believe it's been 27 years. I remember when it was still in beta, and how exciting it was to have an open source alternative to Internet Explorer.

Good times!

Mozilla Firefox – Official GitHub repo

Related Stories