What does HackerNews think of gecko-dev?

All the code you need to build Firefox for Linux, macOS, or Windows is in one Mercurial repo: https://hg.mozilla.org/mozilla-central/

The repo is also mirrored on GitHub for convenience, though PRs are not accepted through GitHub: https://github.com/mozilla/gecko-dev

The build instructions start with a script (“mach bootstrap”) that will download and install all the blessed tools and SDKs needed to build: https://firefox-source-docs.mozilla.org/setup/index.html

Depending on your network and computer, it can be possible to download the source and compile and run your own Firefox build in less than 20 minutes.

There are decentralized monorepos, such as gecko-dev (https://github.com/mozilla/gecko-dev), which presumably has several forks in products like Iceweasel.

I think the monorepo workflows which Git isn't good at are things like branching, code review, and feature/version management. But there's no reason that Git should have to be slow just because a repository is large. It's more things like "merge commits don't scale in a monorepo", which I would agree with, but that's not related to the performance of the index data structure.

But I think it's a valid question. Because for a niche browser (which most of these alternate projects are), mainstream compatibility for all websites doesn't seem like it would be the most important thing. I think the idea of using Gecko[0] is a solid one. :P ;) xx

[0]: https://github.com/mozilla/gecko-dev

Mozilla is still obviously working on Gecko, which is the browser engine powering Firefox. You can check the activity here for instance: https://github.com/mozilla/gecko-dev

I wish someone from Mozilla or MS would comment on this, to be honest. Were they even considered?

Historically, I've heard from various sources that Mozilla may not work at the same pace as some of the large corporations do in upstreaming patches and releases to the code base. This has (according to what I have heard, which may simply rest on rumor/speculation/heresey, mind you) kept a lot of large entities from getting on board.

I've also heard that in building Quantum this is less of an issue, but their code base is a mess, and chromium's is incredibly well documented and clean by comparison.

Anecdotally, I would be inclined to agree with my second statement up front, after just browsing the two, but please compare for yourself

https://github.com/chromium/chromium

https://github.com/mozilla/gecko-dev

In all fairness, GitHub also has much to benefit from this too, playing host of the Mozilla git mirror, which also has a relatively large number of refs: https://github.com/mozilla/gecko-dev

Scalability to large numbers of files and large numbers of changesets.

For the large number of files one https://code.facebook.com/posts/218678814984400/scaling-merc... is one source. There's some earlier discussion of the same issue at https://news.ycombinator.com/item?id=3549679 that goes into some technical details.

There has been some work on git since then to address some of those issues (e.g. see https://blogs.msdn.microsoft.com/bharry/2017/02/03/scaling-g... ) but it's not clear to me that it helped enough to catch up to where Mercurial is for large repos.

For large numbers of changesets, just try running "log" or "annnotate" on any file with a long history in git. I just did this simple experiment:

1) hg clone https://hg.mozilla.org/mozilla-central/

2) git clone https://github.com/mozilla/gecko-dev.git

3) (cd mozilla-central && time hg log dom/base/nsDocument.cpp)

4) (cd gecko-dev && time git log dom/base/nsDocument.cpp)

It's not quite apples to apples because the git repo there has some pre-mercurial CVS history in it. But note that I'm not even using --follow for git and the file _has_ been renamed after the mercurial repo starts, so git is actually finding fewer commits than mercurial is here.

Anyway, if I do the above log calls a few times to make sure the caches are warm, I end up seeing times in the 8s range for git and the 0.8s range (yes, 10x faster) for mercurial.

That all said, most repos do not have millions (or even hundreds of thousands) of changesets or files. So the scalability problems are not problems for most users of either VCS.

I don't know if there's any one location for all the Rust code; it may not make logical sense to put the MP4 parser written in Rust right next to the CSS engine, for example. I believe that https://github.com/mozilla/gecko-dev is a mirror of the repo in question, and so we can use Github's search function to find every file that it detects as being a Rust file: https://github.com/mozilla/gecko-dev/search?l=rust (which finds 3,274 Rust files, 6,701 C files, and 22,722 C++ files).

C and Rust? Firefox looks like a ton of C++ to me: https://github.com/mozilla/gecko-dev