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.
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).
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.
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.
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.
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.
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.
Not sure about that. Git certainly doesn't make it easier by idiosyncratic use of terms and behavior. Why does 'pull' imply 'checkout'?
???
It doesn't.
Why is the user exposed to that? If git needs those files checked out for the merge, does it really have to be in the working tree? Why not in a hidden, ephemeral subdirectory? Leave my working tree alone, I say!
pull is fetch + rebase or merge. You can use fetch instead of pull if you prefer. Or `git remote update`, for that matter.
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.
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
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.
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.
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.
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.
Mercurial is over.
[1] At least some of that may be due to file descriptor leaks: https://github.com/facebook/sapling/issues/464
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.
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.
One other interesting thing I've noticed, mercurial has stopped building windows standalone releases. It's been that way for around 9 months.
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 )
Microsoft hired a git maintainer to improve large repo performance and so it's better than it was.
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.
I mean to be fair so is Firefox
Although now that I think about it, if hg had displayed a steam locomotive, maybe people wouldn't have noticed how slow it was...
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.
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...
> 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...
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.
How so?
Annoys the fuck out of me, this conflating git with GitHub.
Yes, because we're talking about comparing BitBucket and GitHub when both are using git. Did you reply to the wrong comment?
Naah, just misunderstood the context,I think. :-)
It also gets bundled with Jira and Confluence.
Probably the Atlassian product I hate the least.
(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.)
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.
Is there anything in jj that could be used as a substitute?
Similarly, there is no concept of stash. The working-copy-commit model removes the need for a distinct "stash" verb, just like it removes the need for the "index" noun.
(In Git, stashes and the staging area are of course trees of blobs, just like ordinary commits. It's just that the UI surfaces them as distinct nouns.)
> This sounds reasonable but I'd like to somehow distinguish these work-on-progress commits. Is there an equivalent of mercurial commit phases?
There isn't any current notion of phases right now, but we've thought of adding them. At the moment, the main distinction added recently is between "immutable" commits and mutable ones, which is determined by a revset, and that revset by default is something like "Anything published on or an ancestor of a head in the remote." Immutable commits cannot be rewritten to a new commit ID.
Frankly I just tag all of my work-in-progress commits with 'wip:', and I use a revset to select and look through every change authored by me that isn't located in the remote main branch.
We are also thinking about improving the color and iconography of the default output to make immutable vs mutable more distinct. So we're not sure if we even need phases yet, I think...
But what I'm most interested in exploring is support for first-class conflicts. I hate the weird state of existing git conflict resolution.
It’s an extension from Mercurial as the blog post states.
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.
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.
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...