[galkk]

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

I also would expect that Github eventually will also offer mercurial repos.

p.s. And let's not talk about abomination that is GitLFS (starting from the fact that it requires separate subcommand).

[2] https://engineering.fb.com/2014/01/07/core-infra/scaling-mer...

[billllll]

Bitbucket dropped Mercurial support in 2020: 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]

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

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.

[compiler-guy]

> 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

That may be the case for some people, but far from all. Many people who started with cvs or even rcs and have moved on to the newer things as they have appeared still find got annoying and unintuitive. Especially compared to Mercurial.

You use it, because it is now the standard, but you are also very aware of how much cleaner and easier other systems have been.

[acdha]

My experience was comparing multople people who started with Mercurial and later learned Git, and had basically all of what people term “Git problems” with Hg because the hard part was thinking about distributed version control.

I’m not saying Git is perfect but simply that it’s hard to separate the difficulties from learning new concepts and working styles from the tool.

[mrweasel]

> Hg was notably slower for daily use

There was an interview with Linus Torvalds at some point where he points out that Mercurial was one of the tools he tried using to replace Bitkeeper, but found it to be much to slow. Has he tells it in the interview he later learned that the slowness he experienced was due to a bug in Mercurial and had that not been there, git might never have happened.

If that's true it a little sad, but I also wonder if many of us might still be on SVN, Perforce or whatever. Git, by being a product of Linus brought a lot of focus on Git. Bitkeeper never got the same attention, that was a commercial product, but being used for kernel development didn't see to promote it as much as I'd expect.

[HelloNurse]

Bitkeeper was more or less like Subversion, fast, expensive and slightly complicated; you seem to overestimate the relevance and influence of Linux kernel use for the average corporate decision maker who doesn't care about Linux, doesn't care about distributed VC, doesn't care about performance (because it only affects peons), doesn't like to spend money and doesn't like bleeding edge tools.

[fragmede]

We'll never know. But git being used to manage the Linux Kernel did a lot for its asendency. if Mercurial had been the choice, maybe we'd all be on Hghub instead of Github. Bitkeeper's proprietary status is what dampened enthusiasm there.

[oarsinsync]

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

Anecdote follows!

I originally started with cvs, and then later, svn. I struggled when git came along, the workflow felt super cumbersome and I kept tripping over the 3 stage process (working directory, staged for commit, and committed), compared to the 2 stage process for already-tracked files in cvs and svn.

After several years, I still never got used to it, and kept having to google when I’d run into random weird issues, having accidentally gotten my repo into a state that had strayed from the basic happy path. Then I started using hg at work, and life got a whole lot easier.

I still haven’t migrated my personal repos off git into hg, mostly because I haven’t (looked for, or) found an hg equivalent of gitea that I can self host, but from my personal experience, day to day usage of git is way harder than day to day usage of hg.

Then again, it helps that I learned hg on the company dime, instead of on my own time.

[pravus]

> 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

No. I had used CVS, SVN, SVK, Bazaar, and Mercurial for years before I switched to Git. I can generally explain the internals of all of these tools (a DAG) to someone in simple terms in minutes. Overlaying that onto the commands becomes easy.

What Git does is take that concept and wrap it in the worst possible workflow UI. The people that immediately grafted onto the Git community cheered this on for some reason very early and then recanted by saying that you are really supposed to build "porcelain" for Git since it was meant to be a rough tool.

To this day all I see are articles about people's confusions and conniptions over simple things that Git does incorrectly because it's UI is horrible. Most can't even get to the point where they understand the DAG. Even though I know what is supposed to happen it's hard for me to fumble around with simple commands because the naming is inconsistent and I have to research to find solutions. This was rarely an issue with Mercurial and when I talk to people that have used both they seem to share that sentiment.

Git is the PHP of version control. Widely used and very popular but has a lot of architectural problems that make it a total mess.

[pfranz]

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

We recently adopted a tool that uses Perforce as a backend. It's been interesting to try and describe centralized version control to younger engineers who have only used a dcvs like git.

[chx]

That's not a meme, many git commands have switches which make them behave wildly differently creating massive confusion.

[acdha]

Sure, but most of those are things you rarely need and it’s not like Mercurial was an AI which always knew what you meant - anyone who ever tried to explain merge-queues to someone else knows that some concepts are just harder than others.

[chx]

No need for hard concepts.

I am talking of things like "opsie, I don't want to commit this yet" (git reset) and "destroy all my work" (git reset --hard) being a command line switch apart. That's just wrong. That's so wrong I keep git reset --hard safety net around, in fact. https://gist.github.com/chx/85db0ebed1e02ab14b1a65b6024dea29

[mkesper]

Newer versions have improved greatly in that regard, but sure you still find too many tutorials etc. using git checkout for everything.

[guenthert]

> 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

Not sure about that. Git certainly doesn't make it easier by idiosyncratic use of terms and behavior. Why does 'pull' imply 'checkout'?

[CRConrad]

Why should the word "checkout" imply anything particular? (Except leaving and paying for your hotel room?)

[meindnoch]

>Why does 'pull' imply 'checkout'?

???

It doesn't.

[guenthert]

It sadly clobbers your working tree. Not calling that checkout doesn't make it any better. Nothing other than checkout ought to change the working tree -- is that too much to ask?

[guenthert]

> Hg and RCS are the only VCSes I’ve seen require data to be recovered from a backup due to normal usage.

Count yourself lucky then. Git was well known for losing data, so much, that it was featured at xkcd [1]. Well, perhaps not the tool itself, but it's user interface was (more than it is now perhaps) so awkward that users often got it wrong. If you don't make that back-up, you might not even know how much you've lost.

[1] https://xkcd.com/1597/

[acdha]

That’s not really what that xkcd is about but that was kind of my point: it’s a long-running joke but it’s not really true – in reality Git makes it really hard to lose data, and most of the time when people say they lost data what they really meant was that they had a sloppy merge and needed help using reflog to retry it.

I’ve worked in modest sized teams within a larger organization (roughly a hundred developers) and have often been the person people ask for help when something goes wrong; most of our teams went from CVS / Source Safe to Subversion, and then Mercurial to Git, and the big step was really the switch to a distributed system - moving from Hg was largely a non-issue (things got faster, we liked GitLab more for other reasons). The only time Hg lost data was back in the era when rebase was an extension, so it wasn’t the core system’s fault but it was a source of friction.

[otabdeveloper4]

> It's just the network effect

No, it isn't. Git is unopinionated and doesn't try to shove some half-baked idea of "best practices" and "you're doing it wrong" down your throat.

This means there is no friction in adopting Git at the workplace.

[RyanHamilton]

>>This means there is no friction in adopting Git at the workplace. It could be said that the virality (network effect) is higher as it spreads easier. Anything is opinionated it's just whether or not those opinions align with your internal values. It appears git aligns with you.

[postexitus]

my git reset --hard disagrees

[wmf]

FB/Meta replaced Mercurial with Sapling which is git-compatible: https://engineering.fb.com/2022/11/15/open-source/sapling-so...

Mercurial is over.

[rbehrends]

As somebody who has actually been using Sapling (because it provides a much saner UI and mental model than git), the git compatibility of Sapling is at best so-so. It feels more like a stopgap solution while they're evolving their own backend (which I'm pretty sure they use internally, because git just doesn't scale to FB monorepo size and doesn't support their rebase-on-push operation). LFS flat-out doesn't work with Sapling. Force pushing after an amend or rebase is still cumbersome, because you need to explicitly specify (again) the branch you are pushing to. And I'm not sure how bad the file descriptor problem still is that you have (had?) with large repos or submodules [1]; there was a new release recently, but I haven't actually stress-tested that.

[1] At least some of that may be due to file descriptor leaks: https://github.com/facebook/sapling/issues/464

[1letterunixname]

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.

[aseipp]

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.

[Shish2k]

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

[fmajid]

Git has a lot of warts, but if I were to pick an alternative it would be Fossil, not Mercurial.

I believe Meta’s implementation includes server components (Mononoke) that were not open-sourced, or at least not buildable without closed-source dependencies. Same with Microsoft’s fork of git that relies on a virtual filesystem, but that one is open-sourced, if for Windows, not Linux.

[petre]

Mercurial is dead unfortunately. It's been stuck on Python 2. The CLI was saner than Git but it needed Python, which helped with our (better) decision to pick Fossil instead. This was 11 years ago. It's been great, it has everything you need in a single executable which can be statically compiled.

[alwillis]

> Mercurial is dead unfortunately. It's been stuck on Python 2.

Mercurial adopted Python 3 a while ago. Not to mention, huge chunks of it have been rewritten in Rust.

Mercurial has continued to get new features like Changeset Evolution [1] that once you use it, you wonder why all version control systems don’t have it.

[1]: https://www.mercurial-scm.org/doc/evolution/

[rbehrends]

Mercurial runs on Python 3 just fine and has been for a while. In fact, starting with Mercurial 6.2 (from July 2022), Python 2 is no longer supported [1].

[1] https://wiki.mercurial-scm.org/Release6.2

[kyrra]

And Google has been putting much of their investment behind jj.

One other interesting thing I've noticed, mercurial has stopped building windows standalone releases. It's been that way for around 9 months.

[muxator]

I think Matt Harbison takes care of Windows builds. They are bundled with the official TortoiseHg download:

https://tortoisehg.bitbucket.io/download/

I did not use them because I am on linux only, but I see that Matt is active and responsive, both on the mailing list and chasing bugs on the issue tracker on heptapod ( https://foss.heptapod.net/mercurial/tortoisehg/thg )

[depr]

Have they? It seems there's only one Google employee working on it.

[saagarjha]

What’s jj?

[chronogram]

https://github.com/martinvonz/jj a more recent version control system.

[loeg]

The day-to-day workflow at Meta is still using the hg frontend and regular hg commands. I would love to see the git frontend used instead, but, it hasn't happened yet.

[Kilenaitor]

I've switched over to using `sl` commands. Sapling is installed on ODs by default. Main change I had to get used to was `up(date)` became `goto`.

[cozzyd]

I assume this is a different sl than https://man.cx/sl(6)

[mrweasel]

While the real sl (Steam Locomotive) isn't installed on that many systems, I can only imagine the annoyance that it must bring to any former Facebook engineers when they assume that it's the version control

[cozzyd]

I wonder how many typoed invocations of ls correspond to sl commands. Like if you have an update directory.

Although now that I think about it, if hg had displayed a steam locomotive, maybe people wouldn't have noticed how slow it was...

[loeg]

I don't want to learn a 3rd thing that isn't git!

[LAC-Tech]

> Mercurial is over.

I mean to be fair so is Firefox

[nine_k]

Wait until Google starts to suppress ad blockers for real in a few months.

[LAC-Tech]

People will switch to brave, not Firefox.

[lutoma]

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

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

[Blackthorn]

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?

[jeremyjh]

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.

[ayhanfuat]

In the announcement they mentioned that less than 1% of new users were choosing hg. It was probably slightly higher for old users.

> In fact, Mercurial usage on Bitbucket is steadily declining, and the percentage of new Bitbucket users choosing Mercurial has fallen to less than 1%.

https://bitbucket.org/blog/sunsetting-mercurial-support-in-b...

[cmrdporcupine]

FWIW I had stuff on Bitbucket from the Before Atlassian times, in Hg repos. And while I had let it bitrot a bit (too complicated to work on open source stuff with my employer at the time), once they dropped Mercurial support I saw no point in moving it to git and keeping it there so I just pulled it off and move it to github.

I'm sure I'm not the only one. The compelling story about Bitbucket for me was Mercurial.

Plus Atlassian is kind of just an awful company.

[sproingie]

> Plus Atlassian is kind of just an awful company.

How so?

[culi]

Still seems near-sighted. If someone started a new mercurial project what would they choose to host it on? BitBucket basically automatically wins new users by being the only player in the game

[jeremyjh]

They gave away free private repositories when Github was charging $7/month. That's the only reason they had most of the users they had.

[gmueckl]

Not true. I looked at the complete list of hosted projects on Bitbucket just when it was shut down and I recall that at least 10% of all repos ever created on Bitbucket were hg repos.

[ForHackernews]

Isn't Bitbucket owned by Atlassian? Nobody uses any of their products by choice. They sold some enterprise contract to your boss's boss.

[doix]

Bitbucket is not bad. It has features I miss in GitHub, particularly the larger selection of PR merge strategies so I can satisfy my git history OCD.

Probably the Atlassian product I hate the least.

[dilyevsky]

Yes it’s also been rewritten since acquisition which was when hg support was dropped afaik

[jamesfinlayson]

Why was it rewritten?

[dilyevsky]

If i recall correctly the server/enterprise version was completely separate product written in java (as opposed to python which powered original bitbucket.com). I think the java eventually subsumed the cloud product but not too sure of that

[lmm]

They still have a much better PR/review workflow than github. (Imagine github if reviewing showed changes since your last review by default, and it worked, and you didn't have to make junk comments to get something to count as a review, and comments didn't get lost).

[CRConrad]

You're talking Web site, not version control system.

Annoys the fuck out of me, this conflating git with GitHub.

[lmm]

> You're talking Web site, not version control system.

Yes, because we're talking about comparing BitBucket and GitHub when both are using git. Did you reply to the wrong comment?

[CRConrad]

> Did you reply to the wrong comment?

Naah, just misunderstood the context,I think. :-)

[the_mitsuhiko]

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.

[tsimionescu]

One huge advantage for them compared to GitHub is that they offer an on-prem version. That is much more relevant than Hg support of all things.

It also gets bundled with Jira and Confluence.

[gmueckl]

The hosted Bitbucket and Bitbucket Server (formerly called Stash) only share the name. They are completely different implementations and Bitbucket Server never supported Mercurial.

[jamesfinlayson]

GitHub has GitHub Enterprise Server?

[aseipp]

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

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

Any comments about what it does better than git and mercurial?

[plorkyeran]

The big idea that excites me is that it does away with the concept of having uncommitted changes. Instead, every time you save a file in a repository it is automatically committed. It is the logical endpoint of the git workflow where you make lots and lots of little wip commits and then rewrite them into a sensible set of commits later, and the whole UI is designed around making that work well rather than being something that works but constantly feels like it's off the intended path.

[aseipp]

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

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

[marwis]

Lack of staging area kind of sucks. I'd prefer the opposite - having multiple staging areas (like IntelliJ chabgelists) so I can incrementally build multiple changes at the same time.

Is there anything in jj that could be used as a substitute?

[plorkyeran]

`jj split` and `jj move` are the equivalent of git's staging areas. Instead of picking which changes you want to commit, you pick which changes you want to move from the working-copy commit to the target commit you're assembling. It lets you do something very similar to multiple staging areas by having multiple commits that you're moving changes to.

[marwis]

This sounds reasonable but I'd like to somehow distinguish these work-on-progress commits. Is there an equivalent of mercurial commit phases?

[KingMob]

Personally, I like the elimination of staging and stashing. These always seemed like unnecessarily separate concepts.

But what I'm most interested in exploring is support for first-class conflicts. I hate the weird state of existing git conflict resolution.

[numbsafari]

That’s 2014 vintage. Is it still true?

[pineapple_sauce]

Meta uses https://github.com/facebook/sapling see: https://engineering.fb.com/2022/11/15/open-source/sapling-so...

It’s an extension from Mercurial as the blog post states.

[slimginz]

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/

[explodingcamera]

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]

Oh I didn’t realize. Internally we use `hg` commands for everything so I guess it’s just the internal version that supports mercurial

[astrange]

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]

hg split is a lot more tedious to do in git.

[kevin_thibedeau]

Google anointed Mercurial before Git. Google Code was Mercurial and Subversion only until near the end of its days.

[cmrdporcupine]

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]

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]

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.

[barrkel]

https://cacm.acm.org/magazines/2016/7/204032-why-google-stor... is a public reference for Mercurial front-ending Piper.