12 ms·

I'm so glad git won the dvcs war. There was a solid decade where mercurial kept promoting itself as "faster than git*†‡" and every time I tried it wound up bein

I'm so glad git won the dvcs war. There was a solid decade where mercurial kept promoting itself as "faster than git*†‡" and every time I tried it wound up being dog slow (always) or broken (some of the time). Git is fugly but it's fast, reliable, and fugly, and I can work with that.

Leynos 7mo ago
I just used it because I preferred the UX.
forrestthewoods 7mo ago
Mercurial has a strictly superior API. The issue is solely that OG Mercurial was written in Python. Git is super mid. It’s a shame that Git and GitHub are so dominant that VCS tooling has stagnated. It could be so so so much better!
- awesome_dude 7mo ago
  Whatever your opinion on one tool or another might be - it does seem weird that the "market" has been captured by what you are saying is a lesser product. IOW, what do you know that nobody else does?
  - jrochkind1 7mo ago
    Welcome to VHS and Betamax. the superior product does not always win the market.
    - Per_Bothner 7mo ago
      Not always, but in this case the superior product (i.e. VHS) won. At initial release, Beta could only record an hour of content, while VHS could record 2 hours. Huge difference in functionality. The quality difference was there, but pretty modest.
      - jrochkind1 7mo ago
        I suppose one lesson could be that there are different dimensions of superiority, different products may be superior in different ways. Of course, products also can win market dominance for reasons external to the product's quality itself (marketing, monopoly lock-in, other network effects, consumer preferences on something other than product quality itself, etc).
  - esafak 7mo ago
    That worse is better, and some people don't know better or care.
    - dwattttt 7mo ago
      "better" in that sentence is very specific. Worse is also worse, and if you're one of the people for whom the "better" side of a solution doesn't apply, you're left with a mess that people celebrate.
  - guelo 7mo ago
    Network effects and marketing can easily prevent better tools from winning.
    - awesome_dude 7mo ago
      I mean, in the fickle world that is TECH, I am struggling to believe that that's what's happened. I personally went from .latest.latest.latest.use.this (naming versions as latest) to tortoise SVN (which I struggled with) to Git (which I also was one of those "walk around with a few memorised commands" people that don't actually know how to use it) to reading the fine manual (well 2.5 chapters of it) to being an evangalist. I've tried Mercurial, and, frankly, it was just as black magic as Git was to me. That's network effects. But my counter is - I've not found Mercurial to be any better, not at all. I have made multiple attempts to use it, but it's just not doing what I want. And that's why I'm asking, is it any better, or not.
      - WolfeReader 7mo ago
        Mercurial has a more consistent CLI, a really good default GUI (TortoiseHg), and the ability to remember what branch a commit was made on. It's a much easier tool to teach to new developers.
        awesome_dude 7mo ago
        Hmm, that feels a bit subjective - I'm not going to say X is easier than Y when I've just finished saying that I found both tools to have a lot of black magic happening. But what I will point out, for better or worse, people are now looking at LLMs as Git masters, which is effectively making the LLM the UI which is going to have the effect of removing any assumed advantage of whichever is the "superior" UX I do wish to make absolutely clear that I personally am not yet ready to completely delegate VCS work to LLMs - as I have pointed out I have what I like to think of as an advanced understanding of the tools, which affords me the luxury of not having an LLM shoot me in the foot, that is soley reserved as my own doing :)
      - arw0n 7mo ago
  - forrestthewoods 7mo ago
    Worse products win all the time. Inertia is almost impossible to overcome. VHS vs Betamax is a classic. iPod wasn’t the best mp3 player but being a better mp3 player wasn’t enough to claw market share. Google and Meta don’t use Git and GitHub. Sapling and Phabricator much much better (when supported by a massive internal team)
    - aaronbrethorst 7mo ago
      What was the better mp3 player than the iPod?
      - codethief 7mo ago
        Anything from iriver.
      - corndoge 7mo ago
        sansa clip+
      - mi_lk 7mo ago
        unironically Zune is goated in its own way
      - CrimsonRain 7mo ago
        anything from Cowon. Always has been
  - jorams 7mo ago
    So far you've only gotten responses to "how can a worse product win?", and they are valid, but honestly the problem here is that Mercurial is not a better product in at least one very important way: branches. You can visit any resource about git and branches will have a prominent role. Git is very good at branches. Mercurial fans will counter by explaining one of the several different branching options it has available and how it is better than the one git has. They may very well be right. It also doesn't matter, because the fact that there's a discussion about what branching method to use really just means Mercurial doesn't solve branches. For close to 20 years the Mercurial website contained a guide that explained only how to have "branches" by having multiple copies of the repository on your system. It looks like the website has now been updated: it doesn't have any explanation about branches at all that I can find. Instead it links to several different external resources that don't focus on branches either. One of them mentions "topic", introduced in 2015. Maybe that's the answer to Git's branching model. I don't care enough to look into it. By 2015 Git had long since won. Mercurial is a cool toolbox of stuff. Some of them are almost certainly better than git. It's not a better product.
    - LordDragonfang 7mo ago
      This is so strange, because, at a low level, a branch isn't even a "thing" in git. There is no branch object type in git, it's literally just a pointer to a commit, functionally no different from a tag except for the commands that interact with it.
      - fc417fc802 7mo ago
        Meanwhile mercurial has bookmarks. TBF I'm not sure when it got those but they've been around forever at this point. The purpose is served. I think there are (or perhaps were) some product issues regarding the specifics of various workflows. But at least some of that is simply the inertia of entrenched workflows and where there are actual downsides the (IMO substantial) advantages need to be properly weighed against them. Personally I think it just comes down to the status quo. Git is popular because it's popular, not because it's noticably superior.
  - dugmartin 7mo ago
    JWZ is still blocking traffic from HN so you can't click to read this but you can copy/paste it into a new tab or open it in a incognito window: https://www.jwz.org/doc/worse-is-better.html https://www.jwz.org/doc/worse-is-better.html
  - kasey_junk 7mo ago
    GitHub had a business model where public repos were free. BitBucket didn’t. That’s it. That’s why git won, you could put up open source libs with one for free and not the other. Which is extra funny as the centralized service was the most important part of decentralized version control.
    - seniorThrowaway 7mo ago
      >the centralized service was the most important part of decentralized version control. I've often thought this about github
    - awesome_dude 6mo ago
      Apologies for the late reply - but I just saw this and immediately thought So git /did/ have something better than Mercurial after all, it was a 3rd party, but it still meant that it was massively better than Mercurial.
- worldsayshi 7mo ago
  Maybe forgejo has a shot?
  - PeterStuer 7mo ago
    Unfortunatly out-of-the-box llm agents only focus on github support, creating friction.
    - worldsayshi 7mo ago
      So pi.dev + forgejo?
  - ptx 7mo ago
    It doesn't seem to support Mercurial though (not to imply that you were implying that it did). All I can find in this proxy/mirror thing to integrate it by presenting the Mercurial repo as a Git server: https://peterlavalle.github.io/post/forgejo-actions/ https://peterlavalle.github.io/post/forgejo-actions/
- outworlder 7mo ago
  > The issue is solely that OG Mercurial was written in Python. Are we back to "programming language X is slow" assertions? I thought those had died long ago. Better algorithms win over 'better' programming languages every single time. Git is really simple and efficient. You could reimplement it in Python and I doubt it would see any significant slowness. Heck, git was originally implemented as a handful of low level binaries stitched together with shell scripts.
  - forrestthewoods 7mo ago
    They died because everyone knows that Python is infact very very slow. And that’s just totally fine for a vast number of glue operations. It’s amusing you call Git fast. It’s notoriously problematic for large repos such that virtually every BigTech company has made a custom rewrite at some point or another!
    - jstimpfle 7mo ago
      Now that is interesting too, because git is very fast for all I have ever done. It may not scale to Google monorepo size, it would ve the wrong tool for that. But if you are talking Linux kernel source scale, it asolutely, is fast enough even for that. For everything I've ever done, git was practically instant (except network IO of course). It's one of the fastest and most reliable tools I know. If it isn't fast for you, chances are you are on a slow Windows filesysrem additionally impeded by a Virus scanner.
      - forrestthewoods 7mo ago
        The fact that Git has an extremely strong preference for storing full and complete history on every machine is a major annoyance! “Except for network IO” is not a valid excuse imho. Cloning the Linux kernel should take only a few seconds. It does not. This is slow and bad. The mere fact that Git is unable to handle large binary files makes it an unusable tool for literally every project I have ever worked on in my entire career.
        7mo ago
- windward 7mo ago
  Mercurial can't rebase without an extension, or force push. Are you using a definition of strictly superior that means it has fewer features?
  - saagarjha 7mo ago
    When I ask for this people like to explain that these are bad features nobody should want.
    - qsera 7mo ago
      And they would be right, https://news.ycombinator.com/item?id=47766632 https://news.ycombinator.com/item?id=47766632
  - qsera 7mo ago
    Mercurial's model is different from Git that these things you list does not make sense there. Rebase does not make sense in Mercurial because it has the concept of fixed branches. A commit is permanently linked to the branch on which it was made. So you are supposed to use merges. Same with force-pushing.
    - windward 7mo ago
      I know. It's an opinion about how to develop that a lot of people hold - a declining proportion, mind you, like Mecurial's declining market share - and it's one that they're able to represent in Git's model, with Git's features. They're even able to do it without exposing me to it. But the same isn't true in reverse. Strictly superior? Believe me, I tried to have an open mind about it. Then one day I was getting ready to go on a work trip with a half-finished feature on my work laptop, and realised there was simply no in-model way for backing that wip up to the repo. If I lost my laptop, I lost the progress. mercurial-scm fails at SCM.
      - qsera 7mo ago
        >in-model way for backing that wip up to the repo. That is because you have this notion of a "clean history", (which IIUC prevented you from making this permanent wip commit) which in reality does not have a lot of use. For most project, "useful history" or "real history" is better than a "clean" history. That is what mercurial caters to.
raincole 7mo ago
This matches my experience 100%. I was about to write a similar comment before I see yours.
steveklabnik 7mo ago
What is kind of funny here is that you're right locally. At the same time, the larger tech companies (Meta and Google, specifically) ended up building off of hg and not git because (at the time, especially) git cannot scale up to their use cases. So while the git CLI was super fast, and the hg CLI was slow, "performance" means more than just CLI speed. I was never a fan of hg either, but now I can use jj, and get some of those benefits without actually using it directly.
- smallmancontrov 7mo ago
  Right, and I'm glad there are projects serving The Cathedral, but I live in The Bazaar so I'm glad The Bazaar won. The efforts to sell priest robes to fruit vendors were a little silly, but I'm glad they didn't catch on because if they had caught on they no longer would have been silly.
  - dwattttt 7mo ago
    GNU Bazaar thoroughly lost, last release was 2016, Canonical retired it last year: https://en.wikipedia.org/wiki/GNU_Bazaar https://en.wikipedia.org/wiki/GNU_Bazaar
    - hypeatei 7mo ago
      GP is taking about this[0] but it's quite hilarious that a VCS exists with that name. 0: https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar
      - bonzini 7mo ago
        It's not a coincidence, it was called like that as a reference to facilitating distributed development.
- landr0id 7mo ago
  >At the same time, the larger tech companies (Meta and Google, specifically) ended up building off of hg and not git because (at the time, especially) git cannot scale up to their use cases. Fun story: I don't really know what Microsoft's server-side infra looked like when they migrated the OS repo to git (which, contrary to the name, contains more than just stuff related to the Windows OS), but after a few years they started to hit some object scaling limitations where the easiest solution was to just freeze the "os" repo and roll everyone over to "os2".
eqvinox 7mo ago
I remember using darcs, but the repos I was using it with were so small as to performance really not mattering…
- riffraff 7mo ago
  I remember darcs fondly but even with tiny repos (maybe 5-6 people working on it) we hit the "exponential merge" issues. It worked just fine 99% of the time and then 1% it became completely unusable.
- dented42 7mo ago
  I definitely miss Darcs. I still use it very occasionally, but only with very small repos.
bmitc 7mo ago
Git is not remotely fast for large projects.
- Cthulhu_ 7mo ago
  Define "large"; I've never ran into serious performance issues during the ~15 years I've used Git, which either means the projects I've worked in aren't actually large large, or Git is fast enough for most use cases.
  - ezst 7mo ago
    not OP, and indeed git is fast-enough in many cases, but git not cutting it at Google and Facebook scale, combined with the versatility of mercurial (monkeypatching and extensions system) was the reason why they both invested heavily in mercurial instead of git. Among the tricks being used was remotefilelogs, which is a way to "hydrate" content locally on-demand, which was mimicked in git many years later with Microsoft's git-vfs. Same goes with binary/large files that git eventually got as git-lfs. It's funny to think that a big reason for git to be "fast" today is by playing catch-up with mercurial, which carries this "forever stigma" of being slow.
alwillis 7mo ago
> I'm so glad git won the dvcs war. There was a solid decade where mercurial kept promoting itself as "faster than git". It wasn't the Mercurial team saying it was faster than Git; that was Facebook after contributing a bunch of patches after testing Mercurial on their very large mono-repo in 2014 [1]: For our repository, enabling Watchman integration has made Mercurial’s status command more than 5x faster than Git’s status command. Other commands that look for changed files–like diff, update, and commit—also became faster. In fact they liked Mercurial so much they essentially cloned it to create their own dvcs, Sapling [2]. (An aside: Facebook did all of this because it was taking too long getting new engineers up to speed with Git. Shocker.) Today, most of the core of Mercurial has been rewritten in Rust; when Facebook did their testing, Mercurial was nearly 100% Python. That's where the "Mercurial is slow" thing came from; launching a large Python 2.x app took a while back in the day. I was messing with an old Mercurial repo recently… it was like a breath of fresh air. If I can push to GitHub using Mercurial… sign me up. [1]: https://engineering.fb.com/2014/01/07/core-infra/scaling-mercurial-at-facebook/ https://engineering.fb.com/2014/01/07/core-infra/scaling-mer... [2]: https://sapling-scm.com/ https://sapling-scm.com/
- Gabrys1 7mo ago
  You can push to GitHub using Sapling. I wish Sapling open source was given more love, as the experience for non-Facebookers is subpar. No bash completion outside the box, no distro packages, no good help pages, random issues interacting with a Git repo...
  - withinboredom 7mo ago
    Sounds like what my teachers used to say: “a personal problem”. Literally nobody outside FB knows what they’re missing and until they fix that, literally nobody cares.
    - itsdesmond 7mo ago
      > Sounds like what my teachers used to say: “a personal problem”. They don’t sound like a very good teacher.
littlecranky67 7mo ago
I might be the outlier, but am I the only one who doesn't care much about the speed of git? I've been using git since 2011 as my main vcs for personal and professional work as a freelancer contractor. Whenever I "wait" for git, it is either limited by the bandwidth (git clone) or by the amount of commit hooks that I implemented for linting, verification etc. The percentage of time actually spent in git internal execution must be a tiny fraction of my day to day usage. What IS affecting me (and my the teams I work in) is usability and UX experience. I.e. if people would screw up stuff (no matter if in git or mercurial) we spent far more time fixing this - I don't think the impmentation speed would matter here. The only case I can imagine is when doing a full checkout of a big repo, but even there, there is --depth which is quite practical.
- windward 7mo ago
  Isn't it kind of like how you don't care much about the oxygen content of the air around you, but you'd miss it if it was gone? I've done development with Mercurial, simple processes were irritatingly slow, particularly if you stray from the better-supported opinionated path.
- ak217 7mo ago
  I spent a long time educating teams of developers about git's usability quirks. I don't do that as much anymore - partly because the quirks have been worked out, partly because the developers have better guardrails and resources to learn from. This whole time (the past 15 years) git has been getting faster without most of us noticing, because big companies have been investing in speeding it up. The reason you don't notice or care is that they work on a very different scale. Thousands of users, thousands of PRs per day, millions of CI/CD jobs all hitting the repo. Now the cycle is repeating again because these numbers are shooting through the roof because of agentic coding.

Leynos 7mo ago

I just used it because I preferred the UX.

forrestthewoods 7mo ago

Mercurial has a strictly superior API. The issue is solely that OG Mercurial was written in Python. Git is super mid. It’s a shame that Git and GitHub are so dominant that VCS tooling has stagnated. It could be so so so much better!

awesome_dude 7mo ago
Whatever your opinion on one tool or another might be - it does seem weird that the "market" has been captured by what you are saying is a lesser product. IOW, what do you know that nobody else does?
- jrochkind1 7mo ago
  Welcome to VHS and Betamax. the superior product does not always win the market.
  - Per_Bothner 7mo ago
    Not always, but in this case the superior product (i.e. VHS) won. At initial release, Beta could only record an hour of content, while VHS could record 2 hours. Huge difference in functionality. The quality difference was there, but pretty modest.
    - jrochkind1 7mo ago
      I suppose one lesson could be that there are different dimensions of superiority, different products may be superior in different ways. Of course, products also can win market dominance for reasons external to the product's quality itself (marketing, monopoly lock-in, other network effects, consumer preferences on something other than product quality itself, etc).
- esafak 7mo ago
  That worse is better, and some people don't know better or care.
  - dwattttt 7mo ago
    "better" in that sentence is very specific. Worse is also worse, and if you're one of the people for whom the "better" side of a solution doesn't apply, you're left with a mess that people celebrate.
- guelo 7mo ago
  Network effects and marketing can easily prevent better tools from winning.
  - awesome_dude 7mo ago
    I mean, in the fickle world that is TECH, I am struggling to believe that that's what's happened. I personally went from .latest.latest.latest.use.this (naming versions as latest) to tortoise SVN (which I struggled with) to Git (which I also was one of those "walk around with a few memorised commands" people that don't actually know how to use it) to reading the fine manual (well 2.5 chapters of it) to being an evangalist. I've tried Mercurial, and, frankly, it was just as black magic as Git was to me. That's network effects. But my counter is - I've not found Mercurial to be any better, not at all. I have made multiple attempts to use it, but it's just not doing what I want. And that's why I'm asking, is it any better, or not.
    - WolfeReader 7mo ago
      Mercurial has a more consistent CLI, a really good default GUI (TortoiseHg), and the ability to remember what branch a commit was made on. It's a much easier tool to teach to new developers.
      - awesome_dude 7mo ago
        Hmm, that feels a bit subjective - I'm not going to say X is easier than Y when I've just finished saying that I found both tools to have a lot of black magic happening. But what I will point out, for better or worse, people are now looking at LLMs as Git masters, which is effectively making the LLM the UI which is going to have the effect of removing any assumed advantage of whichever is the "superior" UX I do wish to make absolutely clear that I personally am not yet ready to completely delegate VCS work to LLMs - as I have pointed out I have what I like to think of as an advanced understanding of the tools, which affords me the luxury of not having an LLM shoot me in the foot, that is soley reserved as my own doing :)
    - arw0n 7mo ago
- forrestthewoods 7mo ago
  Worse products win all the time. Inertia is almost impossible to overcome. VHS vs Betamax is a classic. iPod wasn’t the best mp3 player but being a better mp3 player wasn’t enough to claw market share. Google and Meta don’t use Git and GitHub. Sapling and Phabricator much much better (when supported by a massive internal team)
  - aaronbrethorst 7mo ago
    What was the better mp3 player than the iPod?
    - codethief 7mo ago
      Anything from iriver.
    - corndoge 7mo ago
      sansa clip+
    - mi_lk 7mo ago
      unironically Zune is goated in its own way
    - CrimsonRain 7mo ago
      anything from Cowon. Always has been
- jorams 7mo ago
  So far you've only gotten responses to "how can a worse product win?", and they are valid, but honestly the problem here is that Mercurial is not a better product in at least one very important way: branches. You can visit any resource about git and branches will have a prominent role. Git is very good at branches. Mercurial fans will counter by explaining one of the several different branching options it has available and how it is better than the one git has. They may very well be right. It also doesn't matter, because the fact that there's a discussion about what branching method to use really just means Mercurial doesn't solve branches. For close to 20 years the Mercurial website contained a guide that explained only how to have "branches" by having multiple copies of the repository on your system. It looks like the website has now been updated: it doesn't have any explanation about branches at all that I can find. Instead it links to several different external resources that don't focus on branches either. One of them mentions "topic", introduced in 2015. Maybe that's the answer to Git's branching model. I don't care enough to look into it. By 2015 Git had long since won. Mercurial is a cool toolbox of stuff. Some of them are almost certainly better than git. It's not a better product.
  - LordDragonfang 7mo ago
    This is so strange, because, at a low level, a branch isn't even a "thing" in git. There is no branch object type in git, it's literally just a pointer to a commit, functionally no different from a tag except for the commands that interact with it.
    - fc417fc802 7mo ago
      Meanwhile mercurial has bookmarks. TBF I'm not sure when it got those but they've been around forever at this point. The purpose is served. I think there are (or perhaps were) some product issues regarding the specifics of various workflows. But at least some of that is simply the inertia of entrenched workflows and where there are actual downsides the (IMO substantial) advantages need to be properly weighed against them. Personally I think it just comes down to the status quo. Git is popular because it's popular, not because it's noticably superior.
- dugmartin 7mo ago
  JWZ is still blocking traffic from HN so you can't click to read this but you can copy/paste it into a new tab or open it in a incognito window: https://www.jwz.org/doc/worse-is-better.html https://www.jwz.org/doc/worse-is-better.html
- kasey_junk 7mo ago
  GitHub had a business model where public repos were free. BitBucket didn’t. That’s it. That’s why git won, you could put up open source libs with one for free and not the other. Which is extra funny as the centralized service was the most important part of decentralized version control.
  - seniorThrowaway 7mo ago
    >the centralized service was the most important part of decentralized version control. I've often thought this about github
  - awesome_dude 6mo ago
    Apologies for the late reply - but I just saw this and immediately thought So git /did/ have something better than Mercurial after all, it was a 3rd party, but it still meant that it was massively better than Mercurial.
worldsayshi 7mo ago
Maybe forgejo has a shot?
- PeterStuer 7mo ago
  Unfortunatly out-of-the-box llm agents only focus on github support, creating friction.
  - worldsayshi 7mo ago
    So pi.dev + forgejo?
- ptx 7mo ago
  It doesn't seem to support Mercurial though (not to imply that you were implying that it did). All I can find in this proxy/mirror thing to integrate it by presenting the Mercurial repo as a Git server: https://peterlavalle.github.io/post/forgejo-actions/ https://peterlavalle.github.io/post/forgejo-actions/
outworlder 7mo ago
> The issue is solely that OG Mercurial was written in Python. Are we back to "programming language X is slow" assertions? I thought those had died long ago. Better algorithms win over 'better' programming languages every single time. Git is really simple and efficient. You could reimplement it in Python and I doubt it would see any significant slowness. Heck, git was originally implemented as a handful of low level binaries stitched together with shell scripts.
- forrestthewoods 7mo ago
  They died because everyone knows that Python is infact very very slow. And that’s just totally fine for a vast number of glue operations. It’s amusing you call Git fast. It’s notoriously problematic for large repos such that virtually every BigTech company has made a custom rewrite at some point or another!
  - jstimpfle 7mo ago
    Now that is interesting too, because git is very fast for all I have ever done. It may not scale to Google monorepo size, it would ve the wrong tool for that. But if you are talking Linux kernel source scale, it asolutely, is fast enough even for that. For everything I've ever done, git was practically instant (except network IO of course). It's one of the fastest and most reliable tools I know. If it isn't fast for you, chances are you are on a slow Windows filesysrem additionally impeded by a Virus scanner.
    - forrestthewoods 7mo ago
      The fact that Git has an extremely strong preference for storing full and complete history on every machine is a major annoyance! “Except for network IO” is not a valid excuse imho. Cloning the Linux kernel should take only a few seconds. It does not. This is slow and bad. The mere fact that Git is unable to handle large binary files makes it an unusable tool for literally every project I have ever worked on in my entire career.
      - 7mo ago
windward 7mo ago
Mercurial can't rebase without an extension, or force push. Are you using a definition of strictly superior that means it has fewer features?
- saagarjha 7mo ago
  When I ask for this people like to explain that these are bad features nobody should want.
  - qsera 7mo ago
    And they would be right, https://news.ycombinator.com/item?id=47766632 https://news.ycombinator.com/item?id=47766632
- qsera 7mo ago
  Mercurial's model is different from Git that these things you list does not make sense there. Rebase does not make sense in Mercurial because it has the concept of fixed branches. A commit is permanently linked to the branch on which it was made. So you are supposed to use merges. Same with force-pushing.
  - windward 7mo ago
    I know. It's an opinion about how to develop that a lot of people hold - a declining proportion, mind you, like Mecurial's declining market share - and it's one that they're able to represent in Git's model, with Git's features. They're even able to do it without exposing me to it. But the same isn't true in reverse. Strictly superior? Believe me, I tried to have an open mind about it. Then one day I was getting ready to go on a work trip with a half-finished feature on my work laptop, and realised there was simply no in-model way for backing that wip up to the repo. If I lost my laptop, I lost the progress. mercurial-scm fails at SCM.
    - qsera 7mo ago
      >in-model way for backing that wip up to the repo. That is because you have this notion of a "clean history", (which IIUC prevented you from making this permanent wip commit) which in reality does not have a lot of use. For most project, "useful history" or "real history" is better than a "clean" history. That is what mercurial caters to.

raincole 7mo ago

This matches my experience 100%. I was about to write a similar comment before I see yours.

steveklabnik 7mo ago

What is kind of funny here is that you're right locally. At the same time, the larger tech companies (Meta and Google, specifically) ended up building off of hg and not git because (at the time, especially) git cannot scale up to their use cases. So while the git CLI was super fast, and the hg CLI was slow, "performance" means more than just CLI speed. I was never a fan of hg either, but now I can use jj, and get some of those benefits without actually using it directly.

smallmancontrov 7mo ago
Right, and I'm glad there are projects serving The Cathedral, but I live in The Bazaar so I'm glad The Bazaar won. The efforts to sell priest robes to fruit vendors were a little silly, but I'm glad they didn't catch on because if they had caught on they no longer would have been silly.
- dwattttt 7mo ago
  GNU Bazaar thoroughly lost, last release was 2016, Canonical retired it last year: https://en.wikipedia.org/wiki/GNU_Bazaar https://en.wikipedia.org/wiki/GNU_Bazaar
  - hypeatei 7mo ago
    GP is taking about this[0] but it's quite hilarious that a VCS exists with that name. 0: https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar
    - bonzini 7mo ago
      It's not a coincidence, it was called like that as a reference to facilitating distributed development.
landr0id 7mo ago
>At the same time, the larger tech companies (Meta and Google, specifically) ended up building off of hg and not git because (at the time, especially) git cannot scale up to their use cases. Fun story: I don't really know what Microsoft's server-side infra looked like when they migrated the OS repo to git (which, contrary to the name, contains more than just stuff related to the Windows OS), but after a few years they started to hit some object scaling limitations where the easiest solution was to just freeze the "os" repo and roll everyone over to "os2".

eqvinox 7mo ago

I remember using darcs, but the repos I was using it with were so small as to performance really not mattering…

riffraff 7mo ago
I remember darcs fondly but even with tiny repos (maybe 5-6 people working on it) we hit the "exponential merge" issues. It worked just fine 99% of the time and then 1% it became completely unusable.
dented42 7mo ago
I definitely miss Darcs. I still use it very occasionally, but only with very small repos.

bmitc 7mo ago

Git is not remotely fast for large projects.

Cthulhu_ 7mo ago
Define "large"; I've never ran into serious performance issues during the ~15 years I've used Git, which either means the projects I've worked in aren't actually large large, or Git is fast enough for most use cases.
- ezst 7mo ago
  not OP, and indeed git is fast-enough in many cases, but git not cutting it at Google and Facebook scale, combined with the versatility of mercurial (monkeypatching and extensions system) was the reason why they both invested heavily in mercurial instead of git. Among the tricks being used was remotefilelogs, which is a way to "hydrate" content locally on-demand, which was mimicked in git many years later with Microsoft's git-vfs. Same goes with binary/large files that git eventually got as git-lfs. It's funny to think that a big reason for git to be "fast" today is by playing catch-up with mercurial, which carries this "forever stigma" of being slow.

alwillis 7mo ago

> I'm so glad git won the dvcs war. There was a solid decade where mercurial kept promoting itself as "faster than git". It wasn't the Mercurial team saying it was faster than Git; that was Facebook after contributing a bunch of patches after testing Mercurial on their very large mono-repo in 2014 [1]: For our repository, enabling Watchman integration has made Mercurial’s status command more than 5x faster than Git’s status command. Other commands that look for changed files–like diff, update, and commit—also became faster. In fact they liked Mercurial so much they essentially cloned it to create their own dvcs, Sapling [2]. (An aside: Facebook did all of this because it was taking too long getting new engineers up to speed with Git. Shocker.) Today, most of the core of Mercurial has been rewritten in Rust; when Facebook did their testing, Mercurial was nearly 100% Python. That's where the "Mercurial is slow" thing came from; launching a large Python 2.x app took a while back in the day. I was messing with an old Mercurial repo recently… it was like a breath of fresh air. If I can push to GitHub using Mercurial… sign me up. [1]: https://engineering.fb.com/2014/01/07/core-infra/scaling-mercurial-at-facebook/ https://engineering.fb.com/2014/01/07/core-infra/scaling-mer... [2]: https://sapling-scm.com/ https://sapling-scm.com/

Gabrys1 7mo ago
You can push to GitHub using Sapling. I wish Sapling open source was given more love, as the experience for non-Facebookers is subpar. No bash completion outside the box, no distro packages, no good help pages, random issues interacting with a Git repo...
- withinboredom 7mo ago
  Sounds like what my teachers used to say: “a personal problem”. Literally nobody outside FB knows what they’re missing and until they fix that, literally nobody cares.
  - itsdesmond 7mo ago
    > Sounds like what my teachers used to say: “a personal problem”. They don’t sound like a very good teacher.

littlecranky67 7mo ago

I might be the outlier, but am I the only one who doesn't care much about the speed of git? I've been using git since 2011 as my main vcs for personal and professional work as a freelancer contractor. Whenever I "wait" for git, it is either limited by the bandwidth (git clone) or by the amount of commit hooks that I implemented for linting, verification etc. The percentage of time actually spent in git internal execution must be a tiny fraction of my day to day usage. What IS affecting me (and my the teams I work in) is usability and UX experience. I.e. if people would screw up stuff (no matter if in git or mercurial) we spent far more time fixing this - I don't think the impmentation speed would matter here. The only case I can imagine is when doing a full checkout of a big repo, but even there, there is --depth which is quite practical.

windward 7mo ago
Isn't it kind of like how you don't care much about the oxygen content of the air around you, but you'd miss it if it was gone? I've done development with Mercurial, simple processes were irritatingly slow, particularly if you stray from the better-supported opinionated path.
ak217 7mo ago
I spent a long time educating teams of developers about git's usability quirks. I don't do that as much anymore - partly because the quirks have been worked out, partly because the developers have better guardrails and resources to learn from. This whole time (the past 15 years) git has been getting faster without most of us noticing, because big companies have been investing in speeding it up. The reason you don't notice or care is that they work on a very different scale. Thousands of users, thousands of PRs per day, millions of CI/CD jobs all hitting the repo. Now the cycle is repeating again because these numbers are shooting through the roof because of agentic coding.