Hacker News

Can't comment on Mercurial, but "for all my personal project where I don't need to care what anyone else thinks" I am using Fossil. Ever since that decision, I've felt a bit, well, held back, or rather, I don't feel quite as comfortable as I do at home when I have to use Git.

My recollection is that it was more of a VHS vs Betamax story than one being strictly superior. When a lot of people were making their decisions, Git was a lot faster in ways that mattered. IIRC, shortly after a lot of places picked Git, Mercurial cut a release that significantly improved performance.

And in a similar vein, Darcs. It unfortunately couldn’t compete with Git on performance, but the user experience is on a whole another level.

Is git really far worse technology than mercurial? I’ve used both for years and to be honest they are pretty similar. What important capabilities does hg have that git does not? Maybe you can argue that hg is more ergonomic, but that’s just polish it doesn’t mean the tech is far better…

Mercurial wasn't the better technology, though. The UX is almost the same as git, diverging in ways that are arguably worse, but the tools were written in much slower Python (initially, and for many years after).

I’ve recently switched to jj and it is truly amazing. It too about a week for me to “get it”. The tool is amazing but I think there’s way too much emphasis on what it does/allows rather than what benefits it brings to your workflow. If they get that marketing right I could see it growing. If not, I’ll keep using it

> I have the feeling that Git winning the war hinges heavily on GitHub being the way to do open source projects

Nah. At the time BitBucket was the better way to do open source projects, and they were Mercurial-first. But eventually they had to add Git support because there was so much demand.

That’s a great point I hadn’t thought of before.

I’m glad there is one clear winner and we’re not in the common position of having 2-3 relevant/semi-relevant choices that you’re frequently asked to switch between depending on which project you’re looking at at the moment.

Git is modern version control, whatever you think of it, and there’s a simplicity to that.

Despite not using anything else, I don't know all the git commands I need to get my job done so I use UIs and my agent. It's just not intuitive enough, some things are just not possible to do right, and I look forward to ditching it.

To be entirely fair nothing in git backend prevents someone to make friendlier frontend.

> Its ergonomics were superior to Git's

That's a matter of taste. I used both for serious work, at the time, and found Git much more usable. My experience with Mercurial was "welcome to Mercurial, how can we help you merge and push your work in progress even though that's not what you want?" My experience with Git was one where I felt in control at all times, had a clear workflow for when I did and didn't want to publish my changes (and for when I wanted to edit them first), and allowed me to quickly make and switch branches within a single working copy.

I don't know what you mean by ergonomics, but I remember trying both Mercurial and Git back in the days after using Subversion before. I didn't like how Mercurial didn't easily let me rewrite history and do stuff like `git commit --ammend` or `git rebase`. Mercurial users kept telling me using an extension to manage patches on top of Mercurial (I think it was quilt).

I agree about the Windows support. hg serve was also nice. Plus TortoiseHg.

Facebook didn’t adopt mercurial until something like 2014? And before that used svn -> git

Facebook has been using their own in-house Sapling/Eden for years and years now. I'm not sure how much similarity remains with open source Mercurial.

I think I liked the Mercurial branching model better than git, due to the branches being a first class record of events. What I did not know is how common the git rebase/clean linear history would become or a desire to change history on merge.

Mercurial had bookmarks that were roughly the same as git branches.

The linear version numbers were quite useful to reason about and use in places that call for a "number" version number, and were useful relative to your "master" clone. That was not the primary way though, it had hashes like git too, that were the same from clone to clone.

Sequentially numbered versions is still used at main Google monorepo (at least did a few years ago), named "changelist number", from perforce. Up to the point that people define extension field numbers in protobufs using their changelist number, to ensure it will never intersect with anyone else.

I always hear it has far better “tooling” but then the comments say that branching sucks, revisions suck and there is no good got stash equivalent - this is like a third of what I use daily with git.

What does “far better tooling” mean exactly, could you give an example of what amazing tools I’m missing out on (never have used anything else but git, when I came to the industry it was already the standard)

> I also did this. Both in hindsight and at the time, I thought Mercurial had far better tooling.

I recall checking Mercurial back in the day and being puzzled by the lack of basic features such as the ability to stash changes. I also recalled that the community was dismissive of the lack of such a basic feature, with comments such as users could always create local branches, of even we could perhaps install a module such as shelve.

That was the image that Mercurial left with me with regards to git: missing critical features and not bothering to bridge the gap.

Not GP but there is a consequence. These days if someone has used version control they almost certainly know Git.

That means pretty much everyone who comes in the door needs Mercurial training, whether formal or informal. You’d get the same effect from still using CVS, SVN, or other things.

That may not be a big issue. If someone understands version control I’d hope they could adapt to another minder pretty fast.

It’s still an issue. There is technically a cost.

FWIW you can still have a staging-area-like workflow with JJ - it's just that while git has "commits", "the staging area", "the working directory", and "stashes" as four separate concepts with four separate toolkits, in JJ all of those things are "commits" and a single toolkit works with all of them :)

It make a lot of sense if you think of repo history as properly immutable, and dispose of the notion that brach is a first class object in the git sense. Bookmakers just pin a checkin hash to a name, and you can have many heads in an hg branch.

What does short lives branches even mean? Make a branch, close it, or merge it.

There was a quote somewhere about Mercurial having a mental model small enough you can fit in your head - and that was the big win for me.

It was also fast and had very clean, easy to contribute to code. I remember submitting a patch and getting a bit of Python education from Matt, which was very useful.

Git is fine but it's inconsistent enough in the interface department, even after all this time, that I still get regularly frustrated. On the other hand, you can't just break a workflow that already exists and I very much appreciate it scales to work far beyond mine.

I do like that the git people are doing the difficult work of improving the UI over time - it's hard to change the engines while the plane is flying!

> Mercurial wasn't as simple as Subversion.

What? Subversion is by far the most complex versioning software I've ever used.

> Git has so many gotchas, bells and whistles

The Git UI leaves a little to be desired. But inside, Git is basically just blobs, trees, commits, and refs. It'd be hard (or impossible?) to find a conceptually simpler versioning system.

Unless git has some hidden way to do changeset evolution (maybe with jujutsu on top?) then no - I'm pretty sure git is strictly less powerful than hg these days.

No, it's the opposite

Olivia uses she/her, and I believe she is now retired :)

I owe her and the Mercurial community a great debt. The community taught me how to think like an engineer building infrastructure and the importance of backwards compatibility, something I've tried to carry forward in tools like cargo-nextest.

That's what I expected - I was sure the Tortoise guys would get it right eventually.

Still Sapling + Eden to make local work on a sparse checkout viable.

Git doesn't have any sort of API either, libgit2 is unofficial.