9 ms·

Interesting, given that Google and Facebook [2], at least, eventually moved to have their repositories offered via Mercurial interface, instead of git. I also

• numbsafari 3y ago
  That’s 2014 vintage. Is it still true?
  • slimginz 3y ago
    Yup! In fact Meta’s implementation is open sourced as Sapling SCM and includes both Mercurial and Git support[1]. Internally the main repository use Mercurial although I believe a few legacy projects still use git. [1] https://sapling-scm.com/ https://sapling-scm.com/
    • explodingcamera 3y ago
      From the documentation, it seems like there is 0 mercurial support. It's its own separate version control system that diverged years ago. You can either use the sapling scm client or git.
      • slimginz 3y ago
        Oh I didn’t realize. Internally we use `hg` commands for everything so I guess it’s just the internal version that supports mercurial
  • pineapple_sauce 3y ago
    Meta uses https://github.com/facebook/sapling https://github.com/facebook/sapling see: https://engineering.fb.com/2022/11/15/open-source/sapling-source-control-scalable/ https://engineering.fb.com/2022/11/15/open-source/sapling-so... It’s an extension from Mercurial as the blog post states.
• lutoma 3y ago
  > I also would expect that Github eventually will also offer mercurial repos. How come? That seems highly unlikely to me, especially when you consider that one of their larger competitors (Bitbucket) had Mercurial support for a long time and then removed it.
  • mrighele 3y ago
    In fact Bitbucket started as a Mercurial hosting service, then added Git support, then dropped Mercurial. From when they dropped Mercurial in 2020 [1]: "Yesterday marked an end of an era for Mercurial users, as Bitbucket announced to no longer support Mercurial repositories after May 2020. Bitbucket, owned by Atlassian, is a web-based version control repository hosting service, for source code and development projects. It has used Mercurial since the beginning in 2008 and then Git since October 2011." [1] https://hub.packtpub.com/bitbucket-to-no-longer-support-mercurial-users-must-migrate-to-git-by-may-2020/ https://hub.packtpub.com/bitbucket-to-no-longer-support-merc...
  • Blackthorn 3y ago
    That change was so dumb. Mercurial support was the bit that put them as something different from github. Once they didn't have it anymore, why would anyone use them at all?
    • the_mitsuhiko 3y ago
      I'm sure they knew what they did. They probably primarily had git users on the service, and the motivation to use Bitbucket is most likely because you already pay for other Atlassian products.
    • jeremyjh 3y ago
      So since you are knowledgeable about the fact that this decision was "dumb", you must also know approximately what proportion of their users were dependent on hg for their workflow ? My priors would put it at less - likely far less - than 1%. But please share your knowledge.
      • 3y ago
• wmf 3y ago
  FB/Meta replaced Mercurial with Sapling which is git-compatible: https://engineering.fb.com/2022/11/15/open-source/sapling-source-control-scalable/ https://engineering.fb.com/2022/11/15/open-source/sapling-so... Mercurial is over.
  • LAC-Tech 3y ago
    > Mercurial is over. I mean to be fair so is Firefox
    • nine_k 3y ago
      Wait until Google starts to suppress ad blockers for real in a few months.
      • LAC-Tech 3y ago
        People will switch to brave, not Firefox.
  • 1letterunixname 3y ago
    Meta's fork/rewrite of hg, Sapling hasn't gone anywhere yet because it needs EdenFS and Mononoke that aren't yet/maybe never FOSS. It's only called hg internally because of legacy reasons but it's completely different. Microsoft hired a git maintainer to improve large repo performance and so it's better than it was.
    • Shish2k 3y ago
      I’ve been using the sapling CLI as my frontend with github as my backend and finding it quite delightful - all the UX niceness from mercurial (and then some), while still being totally compatible with the rest of my team :)
    • aseipp 3y ago
      Sapling can use Mononoke, but it can also use Git repositories as the underlying storage layer with no server at all, and it does so by default in the OSS build. You can use it just fine with GitHub today, but there are rough edges. My understanding is that the work to support OSS builds of Mononoke+EdenFS is happening, but there's no exact timeline right now because (from what I can tell) they basically have to abstract out and write new production storage components for the metadata/object layer, as they can't use their internal ones, obviously.
• billllll 3y ago
  Bitbucket dropped Mercurial support in 2020: https://bitbucket.org/blog/sunsetting-mercurial-support-in-bitbucket https://bitbucket.org/blog/sunsetting-mercurial-support-in-b... I just don't think there is good RoI for implementing Mercurial support. It really isn't about the interface (which I think most people agree hg is better than git). It's just the network effect: most projects use git so everybody learns git and they don't want to learn another tool even if it's better in some ways. At the end of the day, once you pay a higher upfront cost to learn the ~5 git invocations you need, your daily productivity between using git and hg is probably the same. Google and Facebook is different: they have a unique use-case and scale, and massive internal tooling teams supporting their use-cases. Also, as an employee, you're probably more open to different VCS systems because if you learn hg at Facebook, you're learning it on company time whereas if you learn for an open source project, you're learning it on your time.
  • dehrmann 3y ago
    > It's just the network effect It's almost like qwerty vs dvorak in that regard, except git and mercurial were contemporaries. Mercurial isn't quite good enough to displace git, and git has Linus as a promoter which was all it needed to be the leader. That said, I agree that the network effect of having just one is more valuable than mercurial's ergonomics (which could still use a good branch story).
    • acdha 3y ago
      Mercurial also missed the window on performance and safety. If you started using it around 2009 or so, Hg was notably slower for daily use and a lot of people recommended using extensions to match Git features but those extensions were not stable (Hg and RCS are the only VCSes I’ve seen require data to be recovered from a backup due to normal usage). There’s a meme that Git is hard to use but I think it’s conflating the challenges of getting used to version control at all, distributed version control, and any specific tool. I watched a number of developers do that and it was about as much work to go from SVN to either Git or Mercurial, and if they learned the other DVCS it was always easier since they were mapping concepts rather than learning them for the first time. The marginal returns on productivity weren’t worth switching in most cases so it tended to come down to Git being so much faster and, as network effects kicked in, easier to host.
• astrange 3y ago
  I knew the guy who wanted Google Code to be Mercurial based; he pretty much just did it because he liked Python and therefore thought anything written in Python was good.
  • barrkel 3y ago
    hg split is a lot more tedious to do in git.
• aseipp 3y ago
  Google currently uses a fork of Mercurial as the frontend to Piper, but there is work to replace it wholesale, eventually: https://github.com/martinvonz/jj https://github.com/martinvonz/jj (As a disclosure, I'm involved with and contribute to jj, but I don't work for or speak for Google in any way; the above statement is public knowledge.)
  • culi 3y ago
    Any comments about what it does better than git and mercurial?
    • aseipp 3y ago
      I completely rewrote the README recently to be more "user friendly"; does it address some of your question? I'm not trying to be snarky, I'm genuinely interested in if the README is now tantalizing enough to make you interested: https://github.com/martinvonz/jj?tab=readme-ov-file#introduction https://github.com/martinvonz/jj?tab=readme-ov-file#introduc... But in short, it has a better UX than Git by a mile while remaining interoperable at the storage level, so you can use GitHub; it has many of the niceties of Mercurial's UX like revsets, no staging area, and a templating language for log output. Conflict resolution and rebasing is clean, easy, and nearly automatic. It has features neither support, like a real undo command and "operation log"[1]. The UX is smaller and conceptually cleaner; fewer "verbs" that operate on less "nouns", so many things are more regular. It is available as an API (Rust crates) so you can extend it naturally to handle your own workflow, without monkey-patching things. You could even use Mercurial itself as a storage backend, or a custom, centralized server like Google does. Most importantly though, its internal "automatic snapshot model" design is quite elegant and makes the design and internals very clear. And storage system is completely independent and abstracted from this, and many of the other algorithmic details (Git sort of intertwines the data model, the algorithms, and the UX in various ways.) Features like hg changeset evolution, git rerere, and rebase --update-refs are all obsoleted and naturally handled by this design, among other things. Martin, the lead developer, also had a talk at Git Merge 2022 that covers many of the fundamentals. They're all still the same but we're evolving many things rapidly: https://www.youtube.com/watch?v=bx_LGilOuE4 https://www.youtube.com/watch?v=bx_LGilOuE4 [1] Yes I know about the reflog, no it is not equivalent! It only tracks changes made to visible references ("ref" "log") while jj's oplog actually tracks commands invoked, and lets you completely undo individual things in the blink of an eye, or rewind if you wish.
• barrkel 3y ago
  https://cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single-repository/fulltext https://cacm.acm.org/magazines/2016/7/204032-why-google-stor... is a public reference for Mercurial front-ending Piper.
• kevin_thibedeau 3y ago
  Google anointed Mercurial before Git. Google Code was Mercurial and Subversion only until near the end of its days.
  • cmrdporcupine 3y ago
    The reason is the same as for why "fig" was done internally -- git is a DVCS that runs over a filesystem, while Mercurial has an actual protocol, so the storage layer can be plugged out. Presumably for Google Code it was some appengine or bigtable type backend. For fig, I believe it was, somehow, piper.
• cmrdporcupine 3y ago
  My understanding with the Mercurial stuff at Google is it was done that way because Mercurial defines a wire protocol, while Git does not (it expects a filesystem). So when fig was put together, they simply couldn't use git for the intended workflow, because it needed to be able to front-facade the existing CitC/Piper repository. Prior to that, we used to use 'git5' which was kind of git bolted on in front of Piper, and it worked, but it was a little wonky with explicit import and export steps. I tried to use fig a little before I left, and I can't say I was entirely blown away. I used to like Mercurial a decade and a half ago, and learned it before git... but it felt very foreign to me now.
• cookiengineer 3y ago
  I came here to mention that mercurial handles large binaries very well, wheras git LFS is a fustercluck of a workflow. It's like submodules, where people 99% of the time have to add the --init --recursive flags anyways, and yet nobody cares to optimize the workflow. I wish git had better submodules, and better binary asset folders that could be linked and cloned/fetched/pulled/pushed without having to have a complete checkout of the whole repository with all its history. Oh, and automatic pruning would be nice because my git servers constantly run out of HDD space when I don't do git gc regularly, which oftentimes is broken in itself already.