13 ms·

Firefox Development Is Moving from Mercurial to Git

223 points by l0b0 3y ago

snvzz 3y ago
About time.
- Dudester230602 3y ago
  Luckily, by now there are enough tools to hide the insanity of git behind the scenes. Just make sure to avoid the 1980-s way of using it (console).
mgd 3y ago
Is there a reason why they used Mercurial as opposed to git? Did it provide some benefit?
- vardump 3y ago
  Probably tooling and developer mindshare. Might not have much to do with git vs Mercurial technical merits.
  - zilti 3y ago
    "developer mindshare" has become one of the most bullshit reasons to use something.
    - j1elo 3y ago
      "developer mindshare" usually equals better or at least more support. Which is not at all a bullshit reason to use something.
    - sshine 3y ago
      For that reason alone, yes. But not for the reasons that correlate, such as education, tooling.
  - Espressosaurus 3y ago
    Yeah. From a technical standpoint Git is a lot worse in a lot of ways. From an ease-of-use standpoint it's about as much worse as it's possible to be. Still, with Linux behind it, Git won the DVCS wars. Mercurial became an also-ran and now almost nobody uses it. Too bad. We'll need something new and innovative to come out and rid us of constant blogs explaining how Git works because it's too hard to understand how to make it do the things you want it to do. I've been using Git for about 7 years now (5 exclusively) and I know how to use it, but I still have to look things up occasionally because its UI is trash and non-obvious. I didn't have that problem with Mercurial. There, I knew the verb and the built-in help was sufficient to get me where I wanted to go. Worse is better wins again.
    - TerrifiedMouse 3y ago
      > We'll need something new and innovative to come out and rid us of constant blogs explaining how Git works because it's too hard to understand how to make it do the things you want it to do. Read about Jujutsu awhile back. https://news.ycombinator.com/item?id=30398662 https://news.ycombinator.com/item?id=30398662
    - pptr 3y ago
      I really enjoy the simplicity of Googles internal repo (piper). I am quite surprised that no open source variant has been created yet (that I'm aware of).
      - Ygg2 3y ago
        How does piper work?
    - WesolyKubeczek 3y ago
      > Yeah. From a technical standpoint Git is a lot worse in a lot of ways. From an ease-of-use standpoint it's about as much worse as it's possible to be. Ten years ago, when I had started to use git after having used both Subversion and Mercurial, I noticed one thing. Git was FAST. On repositories of the same size, git was blowing Mercurial out of the water and running circles around it, that's how fast it was. It was FAST and it fucking got out of my way and let me work. I don't know the inner workings of either and academic advantages of Mercurial, but I know for a fact it had been a dog and its move to Python 3 had been disastrous. So whichever technical or UX advantages Mercurial might have, I simply don't care anymore.
- hiddencost 3y ago
  https://wiki.mozilla.org/VersionControlSummit2006 https://wiki.mozilla.org/VersionControlSummit2006
- dale_glass 3y ago
  Mercurial came out about a week after Git did. I've not used it in a long time but I recall that it was a lot less confusing than Git to use. But Git definitely won the war, and Mercurial has been disappearing little by little.
- gtsteve 3y ago
  The two came out at roughly the same time and for the first few years it wasn't really obvious which was better. Personally, I chose Mercurial to start with, because I liked the Windows tooling available and it felt a lot more like Subversion, which is what I used previously. However, Git won the mindshare war in the end, so I moved over to that.
  - santiagobasulto 3y ago
    Happened the SAME thing to me. Mercurial felt more natural than git. Back then, Github allowed you to choose the VC and Mercurial and Git were available, I'd always choose Mercurial. I was also using Google Code that allowed for mercurial as well. Ahhhh, thanks for brining back those memories.
    - antod 3y ago
      > Github allowed you to choose the VC and Mercurial and Git were available You're not thinking about BitBucket are you? I thought Github was always git only?
      - pseudalopex 3y ago
        GitHub started with Git and added Subversion. Never Mercurial.
        antod 3y ago
        Oh that's right - I'd forgotten about that april fools joke that wasn't. It was just client compatibility right - the backend was still git from memory? What I mean was that it wasn't like Bitbucket where you chose whether you wanted git or hg for starting your project.
        innocenat 3y ago
        BitBucket was Mercurial-only for quite some times before they added Git (when it was obvious that Git was winning). I think Google Code provide both from the early day (along with Subversion), and maybe also SourceForge.
- deleted 3y ago
  [deleted]
- bsder 3y ago
  Yeah, the mental model of Mercurial is way better. Unfortunately, GitHub got VC funding and caused network effects to kick in. Git came along with GitHub as a parasite much like C came along as a parasite with Unix.
  - adastra22 3y ago
    I'm a huge critic of git, but I think it won out on merits. Git was used by the Linux kernel, and therefore from the beginning scaled better to much larger projects than other DVCS systems.
    - Ygg2 3y ago
      Except it doesn't scale to codebases the size of Facebook and Google.
      - jahav 3y ago
        MS stores windows codebase in a single repo (https://devblogs.microsoft.com/bharry/the-largest-git-repo-on-the-planet/ https://devblogs.microsoft.com/bharry/the-largest-git-repo-o...). 300GB. I don't really see a benefit of having all code of an org in a single repo. Single product, sure. But whole company? Why. Not to mention, these are serious outliers. From security standpoint, it doesn't seem great, from practical side, it's not great (bandwidth cost ect).
        Ygg2 3y ago
        There was similar push by Facebook to improve Mercurial perf and they showed some impressive advantage over Git. It seems it was abandoned eventually for Git.
      - dig1 3y ago
        > Except it doesn't scale to codebases the size of Facebook and Google. Actually, it scales well with large codebases, but the monorepo mental model pushed by FB/Google doesn't match the git workflow model. Git repo design is for a concrete entity: a single tool, binary, service, kernel, whatever. When you start bashing in multiple unrelated projects where you try to have various per-project versioning schemas, it becomes a mess.
- Xenoamorphous 3y ago
  I wonder how much the “victory” of git vs mercurial was influenced by having a big name like Linus Torvalds behind it.
  - VMG 3y ago
    big name and big speed - I distinctly remember how slow "mercurial" was when git started dominating
    - ygra 3y ago
      Since then both had lots of optimizations put into it to work outside their original intended domains. Facebook did a lot to make Mercurial performance on very large repositories tenable. Microsoft did the same for Git to allow their Windows developers to work with Git, which apparently was initially not able to do common operations at all at acceptable speed. But those are big company problems and I suspect the caveats, tradeoffs and solutions matter a lot less for the 99 % of other VCS users.
  - liotier 3y ago
    Not just Torvalds and hosting Linux development: Git solves "big code" problems and large organizations pull the market - including tiny projects for which Git's trade-offs are not optimal, where Mercurial tended to make users happier.
  - bvrmn 3y ago
    For me it was a quite important factor TBH in 2007 when I wanted to try something new outside of SVN. And it was my big argue point to force my company to switch to Git.
  - flohofwoe 3y ago
    IMHO it was Github which made git popular. GH filled a gap left when Sourceforge went down the shitter, and Github was there at the right time to host open source projects for free. The actual version control system used (svn vs git) wasn't all that important. The important feature was free hosting.
- fer 3y ago
  Disclaimer: I haven't touched hg in nearly a decade. hg has (had?) a sane CLI that blows (blew?) git out of the water. I like the power of git, but it either needs external tooling to prevent people from shooting the team in the foot, or relatively thorough study by everyone using it. In practice, for git, most of the time you need some software to protect people from messing up repositories and history (gitlab, github, etc, which honestly you're gonna use anyway), while hg on its own protects you out of the box from most mistakes. All FAANGs I'm familiar with use git, but there are some serious handrails and straps on what you can do. On smaller companies I had so many arguments about rebasing public branches that it's not even funny. For a while I had in the back of my head to create a hg clone that was a wrapper around git, in a way that it'd allow hg-style workflows and protections, while having a faster and more well-known "backend".
  - Ygg2 3y ago
    If hg cli was butt raving mad, it would still be considered "saner" than git. If git was an equivalent modern appliance, it would be against the Geneva convention. I give Git this, it's a bit faster.
    - otabdeveloper4 3y ago
      Git is not opinionated and doesn't care about your workflow, which is why it won in the end. (The downside is that, yes, it's ultimately just a collection of tools, not a "framework" for doing software.)
      - Ygg2 3y ago
        Non-opinionated is not an excuse. It's CLI is an unlearnable mess ( ours vs theirs). I've got 10 years in it and it still bites me in the ass.
        jahav 3y ago
        Maybe, but normal developer interracts with sane parts. Honestly, the biggest problem with git is sane environment for merge conflicts and that is out of scope of git CLI. In most cases, imposing rule for small PRs/feature branches will solve it. git add, git commit, git log, git blame, git push, git rebase -i --onto. That is 95+% of what developers use (maybe an option here or there, like -m or --amend). Merges are done on CI after it passes. There are a lot of arcane parts and switches. git-send-email is likely used a lot on kernel development, but very rarely in the rest of the world. > I've got 10 years in it and it still bites me in the ass. Can you give some examples? I had some problems in the beginnings, but it was because i tried to be "smart". After I embraced KISS, everything works nicely. As long as I keep "public" branches protected, any splash zone is very small and at worst, just redo it(synergy with small PRs).
- deleted 3y ago
  [deleted]
- woadwarrior01 3y ago
  In the early days, the git UX was quite rough around the edges and Mercurial was a lot more idiot proof than git was. Git has evolved significantly since then.
- joewalker 3y ago
  When the decision was made to use Mercurial, Git for Windows wasn't a viable option. If you wanted to develop on Windows, the choices were Mercurial or SVN. Edit: I work for Mozilla, although I didn't in 2006 when I think the decision was made.
- kbrosnan 3y ago
  Git did not run on Windows when Mozilla moved. Git on Windows required running Cygwin was prone to breaking on Cygwin and was slow. This was a pretty big dealbreaker for Mozilla. The imports of Mozilla's ~10 years of CVS dev via the version control's import tool was fragile and none of them imported cleanly without patches. https://soberbuildengineer.com/blog/2007/04/version-control-system-shootout-redux-redux/index.html https://soberbuildengineer.com/blog/2007/04/version-control-... https://soberbuildengineer.com/blog/2006/11/version-control-system-shootout-redux/index.html https://soberbuildengineer.com/blog/2006/11/version-control-...
SuperNinKenDo 3y ago
Anybody got a link that explains why?
- lutrinus 3y ago
  It's right there in the first paragraph: > For a long time Firefox Desktop development has supported both Mercurial and Git users. This dual SCM requirement places a significant burden on teams which are already stretched thin in parts. We have made the decision to move Firefox development to Git.
  - sideshowb 3y ago
    Nitpick, but that quote doesn't explain why not move to mercurial (although I think we all know why)
    - pointlessone 3y ago
      It was Mercurial-only for a long time. Then people got used to git and asked for a mirror to stop dealing with whatever was the layer providing mercurial access for git locally. Apparently, now there are more git people out there than Mercurial.
  - SuperNinKenDo 3y ago
    [flagged]
- deleted 3y ago
  [deleted]
akmittal 3y ago
Git has become de facto standard and with github's popularity most open source projects are loosing potential contributors.
- hahnchen 3y ago
  why would projects be losing potential contributors because github is getting more popular?
  - Jochim 3y ago
    Not using it increases the barrier to entry. Potential contributors are likely to know git and be relatively familiar with the contribution process on Github. Hosting it elsewhere means people are less likely to find it in the first place. Using a different VCS means people are less likely to pick it up. Instead of starting on their contribution they have to install and learn new tooling that is irrelevant to the project itself. Emacs is a pretty good example of this. There are plenty of people who would be interested in making improvements to the project but a much smaller proportion are willing to engage with the email-based process that's required to do so. The crux of the issue is that the social element of an approach is just as important as the technical merit. A technically superior solution will quickly languish if no one can bear to work on it.
    - severino 3y ago
      > Hosting it elsewhere means people are less likely to find it in the first place. But Firefox is a well-known software and, at the same time, a very complex one. I don't think that somebody who struggles figuring out how to contribute via, e.g., Gitlab, will be able to contribute anything useful to the project.
      - Jochim 3y ago
        Motivation and visibility is the problem, not ability. People only have so much time and even insignificant barriers reduce participation. The Emacs example is a bit more involved but still demonstrates this. There's nothing particularly difficult about submitting patches by email but the thought of doing so does put people off. The same goes for the copyright assignment, not difficult at all but reduces participation.
cryptos 3y ago
- We will continue to use Bugzilla, moz-phab, Phabricator, and Lando - Although we'll be hosting the repository on GitHub, our contribution workflow will remain unchanged and we will not be accepting Pull Requests at this time - We're still working through the planning stages, but we're expecting at least six months before the migration begins I understand that this could make sense as a first step, but I guess they could profit if they would go all-in with GitHub and use the tools it offers. Phabricator (https://www.phacility.com/phabricator/ https://www.phacility.com/phabricator/) is even deprecated! And who likes to file bugs in Bugzilla? As sad as it is, I see Firefox losing ground even on the developer side.
- LeanderK 3y ago
  > And who likes to file bugs in Bugzilla? Not only has it been years since I last have heard of bugzilla, I also really resented it! Moving to a modern infrastructure really improves accessibility for developers. For example, GHC (Haskell Compiler) moved to gitlab a few years ago and while previously it was really hard for me to understand the development process nowdays I can follow pull requests and tickets of features I am interested in without any problem. Previously the system was really complicated and, if I remember correctly, Phabricator, mailing list etc. based. Off putting as a newcomer.
  - sydbarrett74 3y ago
    Agreed. Bugzilla just needs to go away. There are so many, far superior issue trackers. Plus Mozilla could allocate resources to Firefox and Thunderbird.
  - pointlessone 3y ago
    Bugzilla is fine. It looks OK. You can subscribe to individual tickets. It doesn’t support emoji reactions or Markdown but it does the job just fine. One thing it does better than GH issues is ticket dependencies even with tree/graph visualization. GH just has no blockers/blocked issues in any form or shape. New ticket form has a few more fields than the default GH issue form but it’s much better than it used to be back in the days and comparable to custom form on GH. You also can log it with your GH account so not much of a barrier there, too. Seriously, try Mozilla’s bugzilla now and see for yourself. It’s probably not as bad as you remember it. Also consider that Mozilla’s bugzilla contains quarter of a century worth of tickets. There’s no way it can be moved to GitHub (or wherever) without loss of data.
kelnos 3y ago
Shame they're going to host it on GitHub, though, rather than self-hosting. I get that the network effects of GitHub will make it easier for potential contributors to get started, but... ugh, just sucks to see a successful open source project moving to a proprietary platform for their hosting.
- deleted 3y ago
  [deleted]
- frankjr 3y ago
  I'm surprised they didn't go with a self-hosted GitLab instance. I've always found GL to be better at handling large projects (projects, groups, sub-groups etc.), not to mention they could easily modify their instance to better integrate with the rest of their services.
  - pointlessone 3y ago
    They don’t seem to plan to use any of the GitHub features. They only use it as a “cloud git hosting”. My guess is if there was as reliable git-web hosting they might as well go with it. By only using GH for repo hosting they’re not locking in themselves and also outsource the tedious parts (infra, backups, etc.).
- severino 3y ago
  Too bad they're going Github, indeed. Keeping away those users that won't be willing (or able) to contribute to the project unless it's hosted on GitHub is something desirable, in my opinion.
  - deleted 3y ago
    [deleted]
mark_undoio 3y ago
Sad to see another Mercurial holdout switch to Git. The latter is ahead in network effects in a massive way - but I always preferred Mercurial. I'd have used it more but - network effects! - used git because of the projects I was working on. The main thing was that the mental model of Mercurial fit in my head and the CLI was predictable and regular, whilst the tool still scaled to large codebases. I find Git wants me to think about its implementation details and internal terminology at unpredictable moments during use. It still gets the job done but it feels like doing random CAPTCHAs in the midst of my work.
- deleted 3y ago
  [deleted]
- ocharles 3y ago
  You might like https://github.com/martinvonz/jj https://github.com/martinvonz/jj, which gives an alternative frontend to Git.
  - mark_undoio 3y ago
    Thanks - that looks interesting. It's especially appealing because it seems to add value beyond just being a neater wrapper to the same operations, it looks like it'll enable new ways of working with the tool.
- sedatk 3y ago
  I totally agree about Mercurial's superior ease of use and simpler mental model. However, it feels quite abandoned. I don't know what caused it though. It's a perfectly viable alternative to Git in my opinion.
  - madeofpalk 3y ago
    I tried contributing to firefox, but figuring out mercurial was a huge discourger.
    - 3y ago
WesolyKubeczek 3y ago
> a significant burden on teams which are already stretched thin in parts Just saying that an insignificant reduction of the C-suite's cushy bonuses and perks could very likely enable hiring quite a few smart people to reduce the burden on teams. If you try to bring the Foundation vs Corporation argument, I'll say outright that this division is pretty much an exercise in creative bookkeeping invented not in the least to circumvent tax agencies and enable the top people to harvest top money while it lasts, while the line workers are being stretched thin.
lifeisstillgood 3y ago
The exact Bugzilla / phab / Haskel style text files shoukd not matter - i mean it's all just tickets. what matters is the level of integration code written by devs to make their lives easier. That's what means it's hard to move. it almost feels like there should be some intermediate target language - like the syntax server that syntax highlighters target (forget the name) not aure how but it feels doable
deleted 3y ago
[deleted]
SoftTalker 3y ago
Risky to depend on a major competitor for your source code repository hosting?
- koolba 3y ago
  What’s the risk? That Microsoft will disable the repo and prevent updates? Or that they’ll read the open source code published to the repo?
  - wredue 3y ago
    Well. One risk now is that Firefox will become a part of copilot, and thus its code will feed Microsoft browser development regardless. This is not what open source is supposed to mean.
- unethical_ban 3y ago
  In a word, no. You're implying that Microsoft would find some reason to shut the project page down. First, I don't think they would. Second firefox is entirely open source, so worrying about trade secrets is no concern. Next, code is in git, so the project could be spun up elsewhere, even if import and export of issues and the association of user accounts would be a one-time hurdle.
Dalewyn 3y ago
I've been ranting in comments about clickbait headlines in recent days, so I'm going to take this moment to say that this kind of headline is absolutely perfect. It's not vague, I immediately know what the article is talking about. I can accurately judge whether I am interested in further reading just from a passing glance. This is how headlines should be written.
psunavy03 3y ago
Honest non-snarky question . . . with Git becoming an industry standard, what is the case for using Mercurial? I'm asking because I've never used it or heard of anyone other than Meta doing so.
- bighead 3y ago
  Megarepo (read monorepo) setups probably ? anecdotally I’ve heard git having a problem with that use case.
  - dotancohen 3y ago
    Considering that the Linux kernel uses git, that particular anecdote's problems could probably be attributed to a cause other than their choice of VCS.
    - sScTE9qEMCxEk34 3y ago
      The Linux kernel is not particularly big by comparison. Although I suppose you could argue the cause is the choice of keeping so much in a single repo (I certainly would).
- readams 3y ago
  Google uses it also, though heavily customized.
- aidenn0 3y ago
  Historically hg had the more intuitive interface[1] and git had better performance. Hg's performance has improved a lot (partly because Meta uses it). Git's interface has improved as well, but I know it too well now to say if it's as intuitive as hg; certainly many hg proponents say it is not. 1: I don't have any hard data for this, but I don't think it's overly controversial.
charcircuit 3y ago
Why not remove git and focus on mercurial if there are not enough resources to support both? Choosing git not only means they need to do a lot of work migrating from mercurial to git, but git is arguably a worse SCM than mercurial, or at the very least not an order of magnitude better to justify a switch.
- MightyBuzzard 3y ago
  [dead]
- sScTE9qEMCxEk34 3y ago
  Because they won't have to teach everyone how to use git, and they will have to teach everyone how to use mercurial
  - charcircuit 3y ago
    git users should pick up mercurial easily due to sharing mostly the same commands and it being simpler. Teaching people git who already know mercurial is harder.

223 points by l0b0 3y ago

snvzz 3y ago

About time.

Dudester230602 3y ago
Luckily, by now there are enough tools to hide the insanity of git behind the scenes. Just make sure to avoid the 1980-s way of using it (console).

mgd 3y ago

Is there a reason why they used Mercurial as opposed to git? Did it provide some benefit?

vardump 3y ago
Probably tooling and developer mindshare. Might not have much to do with git vs Mercurial technical merits.
- zilti 3y ago
  "developer mindshare" has become one of the most bullshit reasons to use something.
  - j1elo 3y ago
    "developer mindshare" usually equals better or at least more support. Which is not at all a bullshit reason to use something.
  - sshine 3y ago
    For that reason alone, yes. But not for the reasons that correlate, such as education, tooling.
- Espressosaurus 3y ago
  Yeah. From a technical standpoint Git is a lot worse in a lot of ways. From an ease-of-use standpoint it's about as much worse as it's possible to be. Still, with Linux behind it, Git won the DVCS wars. Mercurial became an also-ran and now almost nobody uses it. Too bad. We'll need something new and innovative to come out and rid us of constant blogs explaining how Git works because it's too hard to understand how to make it do the things you want it to do. I've been using Git for about 7 years now (5 exclusively) and I know how to use it, but I still have to look things up occasionally because its UI is trash and non-obvious. I didn't have that problem with Mercurial. There, I knew the verb and the built-in help was sufficient to get me where I wanted to go. Worse is better wins again.
  - TerrifiedMouse 3y ago
    > We'll need something new and innovative to come out and rid us of constant blogs explaining how Git works because it's too hard to understand how to make it do the things you want it to do. Read about Jujutsu awhile back. https://news.ycombinator.com/item?id=30398662 https://news.ycombinator.com/item?id=30398662
  - pptr 3y ago
    I really enjoy the simplicity of Googles internal repo (piper). I am quite surprised that no open source variant has been created yet (that I'm aware of).
    - Ygg2 3y ago
      How does piper work?
  - WesolyKubeczek 3y ago
    > Yeah. From a technical standpoint Git is a lot worse in a lot of ways. From an ease-of-use standpoint it's about as much worse as it's possible to be. Ten years ago, when I had started to use git after having used both Subversion and Mercurial, I noticed one thing. Git was FAST. On repositories of the same size, git was blowing Mercurial out of the water and running circles around it, that's how fast it was. It was FAST and it fucking got out of my way and let me work. I don't know the inner workings of either and academic advantages of Mercurial, but I know for a fact it had been a dog and its move to Python 3 had been disastrous. So whichever technical or UX advantages Mercurial might have, I simply don't care anymore.
hiddencost 3y ago
https://wiki.mozilla.org/VersionControlSummit2006 https://wiki.mozilla.org/VersionControlSummit2006
dale_glass 3y ago
Mercurial came out about a week after Git did. I've not used it in a long time but I recall that it was a lot less confusing than Git to use. But Git definitely won the war, and Mercurial has been disappearing little by little.
gtsteve 3y ago
The two came out at roughly the same time and for the first few years it wasn't really obvious which was better. Personally, I chose Mercurial to start with, because I liked the Windows tooling available and it felt a lot more like Subversion, which is what I used previously. However, Git won the mindshare war in the end, so I moved over to that.
- santiagobasulto 3y ago
  Happened the SAME thing to me. Mercurial felt more natural than git. Back then, Github allowed you to choose the VC and Mercurial and Git were available, I'd always choose Mercurial. I was also using Google Code that allowed for mercurial as well. Ahhhh, thanks for brining back those memories.
  - antod 3y ago
    > Github allowed you to choose the VC and Mercurial and Git were available You're not thinking about BitBucket are you? I thought Github was always git only?
    - pseudalopex 3y ago
      GitHub started with Git and added Subversion. Never Mercurial.
      - antod 3y ago
        Oh that's right - I'd forgotten about that april fools joke that wasn't. It was just client compatibility right - the backend was still git from memory? What I mean was that it wasn't like Bitbucket where you chose whether you wanted git or hg for starting your project.
        innocenat 3y ago
        BitBucket was Mercurial-only for quite some times before they added Git (when it was obvious that Git was winning). I think Google Code provide both from the early day (along with Subversion), and maybe also SourceForge.
deleted 3y ago
[deleted]
bsder 3y ago
Yeah, the mental model of Mercurial is way better. Unfortunately, GitHub got VC funding and caused network effects to kick in. Git came along with GitHub as a parasite much like C came along as a parasite with Unix.
- adastra22 3y ago
  I'm a huge critic of git, but I think it won out on merits. Git was used by the Linux kernel, and therefore from the beginning scaled better to much larger projects than other DVCS systems.
  - Ygg2 3y ago
    Except it doesn't scale to codebases the size of Facebook and Google.
    - jahav 3y ago
      MS stores windows codebase in a single repo (https://devblogs.microsoft.com/bharry/the-largest-git-repo-on-the-planet/ https://devblogs.microsoft.com/bharry/the-largest-git-repo-o...). 300GB. I don't really see a benefit of having all code of an org in a single repo. Single product, sure. But whole company? Why. Not to mention, these are serious outliers. From security standpoint, it doesn't seem great, from practical side, it's not great (bandwidth cost ect).
      - Ygg2 3y ago
        There was similar push by Facebook to improve Mercurial perf and they showed some impressive advantage over Git. It seems it was abandoned eventually for Git.
    - dig1 3y ago
      > Except it doesn't scale to codebases the size of Facebook and Google. Actually, it scales well with large codebases, but the monorepo mental model pushed by FB/Google doesn't match the git workflow model. Git repo design is for a concrete entity: a single tool, binary, service, kernel, whatever. When you start bashing in multiple unrelated projects where you try to have various per-project versioning schemas, it becomes a mess.
Xenoamorphous 3y ago
I wonder how much the “victory” of git vs mercurial was influenced by having a big name like Linus Torvalds behind it.
- VMG 3y ago
  big name and big speed - I distinctly remember how slow "mercurial" was when git started dominating
  - ygra 3y ago
    Since then both had lots of optimizations put into it to work outside their original intended domains. Facebook did a lot to make Mercurial performance on very large repositories tenable. Microsoft did the same for Git to allow their Windows developers to work with Git, which apparently was initially not able to do common operations at all at acceptable speed. But those are big company problems and I suspect the caveats, tradeoffs and solutions matter a lot less for the 99 % of other VCS users.
- liotier 3y ago
  Not just Torvalds and hosting Linux development: Git solves "big code" problems and large organizations pull the market - including tiny projects for which Git's trade-offs are not optimal, where Mercurial tended to make users happier.
- bvrmn 3y ago
  For me it was a quite important factor TBH in 2007 when I wanted to try something new outside of SVN. And it was my big argue point to force my company to switch to Git.
- flohofwoe 3y ago
  IMHO it was Github which made git popular. GH filled a gap left when Sourceforge went down the shitter, and Github was there at the right time to host open source projects for free. The actual version control system used (svn vs git) wasn't all that important. The important feature was free hosting.
fer 3y ago
Disclaimer: I haven't touched hg in nearly a decade. hg has (had?) a sane CLI that blows (blew?) git out of the water. I like the power of git, but it either needs external tooling to prevent people from shooting the team in the foot, or relatively thorough study by everyone using it. In practice, for git, most of the time you need some software to protect people from messing up repositories and history (gitlab, github, etc, which honestly you're gonna use anyway), while hg on its own protects you out of the box from most mistakes. All FAANGs I'm familiar with use git, but there are some serious handrails and straps on what you can do. On smaller companies I had so many arguments about rebasing public branches that it's not even funny. For a while I had in the back of my head to create a hg clone that was a wrapper around git, in a way that it'd allow hg-style workflows and protections, while having a faster and more well-known "backend".
- Ygg2 3y ago
  If hg cli was butt raving mad, it would still be considered "saner" than git. If git was an equivalent modern appliance, it would be against the Geneva convention. I give Git this, it's a bit faster.
  - otabdeveloper4 3y ago
    Git is not opinionated and doesn't care about your workflow, which is why it won in the end. (The downside is that, yes, it's ultimately just a collection of tools, not a "framework" for doing software.)
    - Ygg2 3y ago
      Non-opinionated is not an excuse. It's CLI is an unlearnable mess ( ours vs theirs). I've got 10 years in it and it still bites me in the ass.
      - jahav 3y ago
        Maybe, but normal developer interracts with sane parts. Honestly, the biggest problem with git is sane environment for merge conflicts and that is out of scope of git CLI. In most cases, imposing rule for small PRs/feature branches will solve it. git add, git commit, git log, git blame, git push, git rebase -i --onto. That is 95+% of what developers use (maybe an option here or there, like -m or --amend). Merges are done on CI after it passes. There are a lot of arcane parts and switches. git-send-email is likely used a lot on kernel development, but very rarely in the rest of the world. > I've got 10 years in it and it still bites me in the ass. Can you give some examples? I had some problems in the beginnings, but it was because i tried to be "smart". After I embraced KISS, everything works nicely. As long as I keep "public" branches protected, any splash zone is very small and at worst, just redo it(synergy with small PRs).
deleted 3y ago
[deleted]
woadwarrior01 3y ago
In the early days, the git UX was quite rough around the edges and Mercurial was a lot more idiot proof than git was. Git has evolved significantly since then.
joewalker 3y ago
When the decision was made to use Mercurial, Git for Windows wasn't a viable option. If you wanted to develop on Windows, the choices were Mercurial or SVN. Edit: I work for Mozilla, although I didn't in 2006 when I think the decision was made.
kbrosnan 3y ago
Git did not run on Windows when Mozilla moved. Git on Windows required running Cygwin was prone to breaking on Cygwin and was slow. This was a pretty big dealbreaker for Mozilla. The imports of Mozilla's ~10 years of CVS dev via the version control's import tool was fragile and none of them imported cleanly without patches. https://soberbuildengineer.com/blog/2007/04/version-control-system-shootout-redux-redux/index.html https://soberbuildengineer.com/blog/2007/04/version-control-... https://soberbuildengineer.com/blog/2006/11/version-control-system-shootout-redux/index.html https://soberbuildengineer.com/blog/2006/11/version-control-...

SuperNinKenDo 3y ago

Anybody got a link that explains why?

lutrinus 3y ago
It's right there in the first paragraph: > For a long time Firefox Desktop development has supported both Mercurial and Git users. This dual SCM requirement places a significant burden on teams which are already stretched thin in parts. We have made the decision to move Firefox development to Git.
- sideshowb 3y ago
  Nitpick, but that quote doesn't explain why not move to mercurial (although I think we all know why)
  - pointlessone 3y ago
    It was Mercurial-only for a long time. Then people got used to git and asked for a mirror to stop dealing with whatever was the layer providing mercurial access for git locally. Apparently, now there are more git people out there than Mercurial.
- SuperNinKenDo 3y ago
  [flagged]
deleted 3y ago
[deleted]

akmittal 3y ago

Git has become de facto standard and with github's popularity most open source projects are loosing potential contributors.

hahnchen 3y ago
why would projects be losing potential contributors because github is getting more popular?
- Jochim 3y ago
  Not using it increases the barrier to entry. Potential contributors are likely to know git and be relatively familiar with the contribution process on Github. Hosting it elsewhere means people are less likely to find it in the first place. Using a different VCS means people are less likely to pick it up. Instead of starting on their contribution they have to install and learn new tooling that is irrelevant to the project itself. Emacs is a pretty good example of this. There are plenty of people who would be interested in making improvements to the project but a much smaller proportion are willing to engage with the email-based process that's required to do so. The crux of the issue is that the social element of an approach is just as important as the technical merit. A technically superior solution will quickly languish if no one can bear to work on it.
  - severino 3y ago
    > Hosting it elsewhere means people are less likely to find it in the first place. But Firefox is a well-known software and, at the same time, a very complex one. I don't think that somebody who struggles figuring out how to contribute via, e.g., Gitlab, will be able to contribute anything useful to the project.
    - Jochim 3y ago
      Motivation and visibility is the problem, not ability. People only have so much time and even insignificant barriers reduce participation. The Emacs example is a bit more involved but still demonstrates this. There's nothing particularly difficult about submitting patches by email but the thought of doing so does put people off. The same goes for the copyright assignment, not difficult at all but reduces participation.

cryptos 3y ago

- We will continue to use Bugzilla, moz-phab, Phabricator, and Lando - Although we'll be hosting the repository on GitHub, our contribution workflow will remain unchanged and we will not be accepting Pull Requests at this time - We're still working through the planning stages, but we're expecting at least six months before the migration begins I understand that this could make sense as a first step, but I guess they could profit if they would go all-in with GitHub and use the tools it offers. Phabricator (https://www.phacility.com/phabricator/ https://www.phacility.com/phabricator/) is even deprecated! And who likes to file bugs in Bugzilla? As sad as it is, I see Firefox losing ground even on the developer side.

LeanderK 3y ago
> And who likes to file bugs in Bugzilla? Not only has it been years since I last have heard of bugzilla, I also really resented it! Moving to a modern infrastructure really improves accessibility for developers. For example, GHC (Haskell Compiler) moved to gitlab a few years ago and while previously it was really hard for me to understand the development process nowdays I can follow pull requests and tickets of features I am interested in without any problem. Previously the system was really complicated and, if I remember correctly, Phabricator, mailing list etc. based. Off putting as a newcomer.
- sydbarrett74 3y ago
  Agreed. Bugzilla just needs to go away. There are so many, far superior issue trackers. Plus Mozilla could allocate resources to Firefox and Thunderbird.
- pointlessone 3y ago
  Bugzilla is fine. It looks OK. You can subscribe to individual tickets. It doesn’t support emoji reactions or Markdown but it does the job just fine. One thing it does better than GH issues is ticket dependencies even with tree/graph visualization. GH just has no blockers/blocked issues in any form or shape. New ticket form has a few more fields than the default GH issue form but it’s much better than it used to be back in the days and comparable to custom form on GH. You also can log it with your GH account so not much of a barrier there, too. Seriously, try Mozilla’s bugzilla now and see for yourself. It’s probably not as bad as you remember it. Also consider that Mozilla’s bugzilla contains quarter of a century worth of tickets. There’s no way it can be moved to GitHub (or wherever) without loss of data.

kelnos 3y ago

Shame they're going to host it on GitHub, though, rather than self-hosting. I get that the network effects of GitHub will make it easier for potential contributors to get started, but... ugh, just sucks to see a successful open source project moving to a proprietary platform for their hosting.

deleted 3y ago
[deleted]
frankjr 3y ago
I'm surprised they didn't go with a self-hosted GitLab instance. I've always found GL to be better at handling large projects (projects, groups, sub-groups etc.), not to mention they could easily modify their instance to better integrate with the rest of their services.
- pointlessone 3y ago
  They don’t seem to plan to use any of the GitHub features. They only use it as a “cloud git hosting”. My guess is if there was as reliable git-web hosting they might as well go with it. By only using GH for repo hosting they’re not locking in themselves and also outsource the tedious parts (infra, backups, etc.).
severino 3y ago
Too bad they're going Github, indeed. Keeping away those users that won't be willing (or able) to contribute to the project unless it's hosted on GitHub is something desirable, in my opinion.
- deleted 3y ago
  [deleted]

mark_undoio 3y ago

Sad to see another Mercurial holdout switch to Git. The latter is ahead in network effects in a massive way - but I always preferred Mercurial. I'd have used it more but - network effects! - used git because of the projects I was working on. The main thing was that the mental model of Mercurial fit in my head and the CLI was predictable and regular, whilst the tool still scaled to large codebases. I find Git wants me to think about its implementation details and internal terminology at unpredictable moments during use. It still gets the job done but it feels like doing random CAPTCHAs in the midst of my work.

deleted 3y ago
[deleted]
ocharles 3y ago
You might like https://github.com/martinvonz/jj https://github.com/martinvonz/jj, which gives an alternative frontend to Git.
- mark_undoio 3y ago
  Thanks - that looks interesting. It's especially appealing because it seems to add value beyond just being a neater wrapper to the same operations, it looks like it'll enable new ways of working with the tool.
sedatk 3y ago
I totally agree about Mercurial's superior ease of use and simpler mental model. However, it feels quite abandoned. I don't know what caused it though. It's a perfectly viable alternative to Git in my opinion.
- madeofpalk 3y ago
  I tried contributing to firefox, but figuring out mercurial was a huge discourger.
  - 3y ago

WesolyKubeczek 3y ago

> a significant burden on teams which are already stretched thin in parts Just saying that an insignificant reduction of the C-suite's cushy bonuses and perks could very likely enable hiring quite a few smart people to reduce the burden on teams. If you try to bring the Foundation vs Corporation argument, I'll say outright that this division is pretty much an exercise in creative bookkeeping invented not in the least to circumvent tax agencies and enable the top people to harvest top money while it lasts, while the line workers are being stretched thin.

lifeisstillgood 3y ago

The exact Bugzilla / phab / Haskel style text files shoukd not matter - i mean it's all just tickets. what matters is the level of integration code written by devs to make their lives easier. That's what means it's hard to move. it almost feels like there should be some intermediate target language - like the syntax server that syntax highlighters target (forget the name) not aure how but it feels doable

deleted 3y ago

[deleted]

SoftTalker 3y ago

Risky to depend on a major competitor for your source code repository hosting?

koolba 3y ago
What’s the risk? That Microsoft will disable the repo and prevent updates? Or that they’ll read the open source code published to the repo?
- wredue 3y ago
  Well. One risk now is that Firefox will become a part of copilot, and thus its code will feed Microsoft browser development regardless. This is not what open source is supposed to mean.
unethical_ban 3y ago
In a word, no. You're implying that Microsoft would find some reason to shut the project page down. First, I don't think they would. Second firefox is entirely open source, so worrying about trade secrets is no concern. Next, code is in git, so the project could be spun up elsewhere, even if import and export of issues and the association of user accounts would be a one-time hurdle.

Dalewyn 3y ago

I've been ranting in comments about clickbait headlines in recent days, so I'm going to take this moment to say that this kind of headline is absolutely perfect. It's not vague, I immediately know what the article is talking about. I can accurately judge whether I am interested in further reading just from a passing glance. This is how headlines should be written.

psunavy03 3y ago

Honest non-snarky question . . . with Git becoming an industry standard, what is the case for using Mercurial? I'm asking because I've never used it or heard of anyone other than Meta doing so.

bighead 3y ago
Megarepo (read monorepo) setups probably ? anecdotally I’ve heard git having a problem with that use case.
- dotancohen 3y ago
  Considering that the Linux kernel uses git, that particular anecdote's problems could probably be attributed to a cause other than their choice of VCS.
  - sScTE9qEMCxEk34 3y ago
    The Linux kernel is not particularly big by comparison. Although I suppose you could argue the cause is the choice of keeping so much in a single repo (I certainly would).
readams 3y ago
Google uses it also, though heavily customized.
aidenn0 3y ago
Historically hg had the more intuitive interface[1] and git had better performance. Hg's performance has improved a lot (partly because Meta uses it). Git's interface has improved as well, but I know it too well now to say if it's as intuitive as hg; certainly many hg proponents say it is not. 1: I don't have any hard data for this, but I don't think it's overly controversial.

charcircuit 3y ago

Why not remove git and focus on mercurial if there are not enough resources to support both? Choosing git not only means they need to do a lot of work migrating from mercurial to git, but git is arguably a worse SCM than mercurial, or at the very least not an order of magnitude better to justify a switch.

MightyBuzzard 3y ago
[dead]
sScTE9qEMCxEk34 3y ago
Because they won't have to teach everyone how to use git, and they will have to teach everyone how to use mercurial
- charcircuit 3y ago
  git users should pick up mercurial easily due to sharing mostly the same commands and it being simpler. Teaching people git who already know mercurial is harder.