> Aside: I prefer Mercurial myself, and I hope to keep using it for personal projects until I die (:

One of my favorite stories happened three or four jobs ago... at this job I kept a giant whiteboard that I had swiped from a conf room, behind my cubicle. And whenever anybody asked questions we put it up on the board. We were an SVN shop and someone had asked how Git worked and I was like "do you want me to explain Git, which is harder to understand, or Mercurial, which is basically the same but a little easier if you're coming from SVN?" and they said Mercurial. So that is how for a week or two a set of sketched diagrams sat around behind me describing Mercurial.

So while that was happening, I was in the middle of some big commit, this guy Cal comes over. Cal is, we'd classify him as nontechnical but he's essentially the Product Owner for the stuff I'm building, he's the one whose workflows the software needs to enable. And I motion to him that I need 5 minutes and finish my thought and save and commit and whatever else, take off my headphones and ask "what's up, Cal?"

He has been staring at the diagram for those minutes, bored, and this non-technical user says, "okay, so let me see if I got this straight, inside some folder there's another folder named dot-h-g that is a repo..." and goes on to explain everything about Mercurial from a simple diagram, except that he can't figure out what problem it solves. And so I tell him, "you know how on fileserv everybody has to back up every file by appending a timestamp? software developers use these commits instead, so that every commit tells you who changed it and they have to say why they changed it, and that's how you save it," and his eyes kind of go wide and he's like "why don't we have this?!" and I'm like "you could! let me show you TortoiseHg..." and he really liked it, and of course then couldn't convince anybody to actually use it. (There's a problem where you really need to lock, say, an XLSX file.)

Mercurial is always to my mind the version control system that a typical nontechnical office worker could appreciate just from looking at a whiteboard diagram.

Author here.

> my goodness did they beat around the bush w/regard to their actual contribution to this process (per the title).

Fair point. I came up with the title first. Then as the content grew large and diluted the essence of the title, I reconsidered, but ended up sticking to it as a shameless clickbait.

> Originally, separate clones was the recommended way to do "topic branches" in Mercurial (not to be confused with "named branches").

That still leaves the question "why topic branches rather than named branches?". For the needs of the rapid release process, named branches could have been used, but weren't. I haven't tried to contact the people involved at the time to have a definite answer. It's not /that/ important, and I'm not /that/ curious.

One of the biggest problems with Mercurial is that they took a long time for histedit to become a usable workflow. I speculate (without any evidence, so this could be entirely wrong) that this is because many Mercurial contributors preferred MQ over editing history for local patches. (Certainly I knew many Gecko developers who swore by MQ.)

Coming from Git, with the git rebase --interactive flow coupled with the reflog to provide a backup to let you undo any mistakes, MQ was awful. Your choices were (1) allow hg qrefresh to overwrite the old contents of your patches and hope you never made mistakes, or (2) make your patchqueue an hg repo and have to look at second-order diffs. (I chose option (3)--symlink my patchqueue into Dropbox so that I could use Dropbox's history feature as a kind of poor man's reflog.) And to top it all off, MQ didn't understand three-way merge logic the way git rebase does. This workflow seems to me clearly worse than Git's tools, and I'll never understand why so many developers at Mozilla claimed to prefer MQ over Git.

> Originally, separate clones was the recommended way to do "topic branches" in Mercurial

This is still what the Guide on the Mercurial site mentions as the "basic workflow" for working on separate features. Named branches are considered "advanced", and bookmarks are an afterthought entirely.

About 10 years ago, after reading a lot about how hg was more intuitive than git, I decided to give it a try. I was already using git branches a lot, so this was definitely not a good first impression.

> Aside: I prefer Mercurial myself, and I hope to keep using it for personal projects until I die (:

Same here. It is one of the minor tragedies that git won the popularity contest when mercurial is so much more pleasant.

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.

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

Mercurial is over.

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

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

That’s 2014 vintage. Is it still true?

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.

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

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.

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.

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

Git functionality is great. But the CLI just kind of grew in a nonsensical way. No serious effort seems to have been made on UX consistency and verb/noun names.

People who've been using it for years don't notice, they don't even think about it. But when coming from scratch, it's anything but intuitive. The CLI is not discoverable in a reasonable way.

That and there's so many ways to use it.

Mercurial had the advantage of having a much more consistent UX. Though these days I'm sure I'd struggle with it, because I'm so used to git.

Mercurial was never trying to "replace" git. All of these guys came out at the same time. Git got headspace because Linux used it and GitHub was a "cool" Ruby on Rails site, run by cool web 2.0 kids, same era as the rise of Twitter, etc. (And also down all the time, just like Twitter).

Essentially, the problem with git is - it is a tool that is simple in its internals, but with a complex/confusing UI. The only way for someone to feel somewhat in comfortable with git is to have a good conceptual model for how it works internally. Once you have that mental model, you feel like a magician with git, but for beginners, it is a source of endless confusion and fear.

The sheer functionality of git is amazing. The number of times I have encountered a new situation and used a previously unknown (to me) feature, or (equally as impressive) been able to harness the flexibility of the software to wrangle some strange edge case are innumerable. All that while also being lightning fast.

Despite having 14 years of experience with Git, I still can't use it without Stackoverflow for any non-daily task. And I've read the internals back in 2008 and understand this, but it doesn't make it any clear how merges, conflict resolution, or amendments to commits work. Absolutely confusing. In Mecrurial a lot more stuff is clear and easy to remember.

Example: I tried rebasing or merging, and got merge conflicts. Started resolving them, git-added some of files, but got stuck, and want to get back to the last commit. git-reset doesn't work. How do I get there? No idea. How does the knowledge of commit hashes, branches and staging area help me? It doesn't.

> after so many years

This is why so many people dislike git. It's a base tool that should have an obvious workflow and very few pitfalls. Instead it allows one to do just about anything at anytime without giving much of a fuck about any resulting mess. All blade, no handle. It's a tool for Linus, by Linus. The average corporate coder is not Linus and doesn't have Linus problems. People don't want a Merkle tree manager, they want a workflow.

Aside from the terrible UI that several other people have mentioned, there are some other things that Git does badly (though I don't know if Mercurial does better):

* Large projects. It has poor monorepo support (especially on Linux), and also poor multirepos support (submodules are really buggy).

* Large files. LFS is a PoC-level hack; not a proper solution.

* Conflict resolution. The default diff algorithm is very dumb, and even with `zdiff3` it doesn't quite give you enough information to easily resolve all conflicts.

  phases
  revsets (query language for revisions, they also have filesets for the files)
  hg grep --diff
  hg fa --deleted
  hg absorb

I could go into some detail here why Git is the harder to use system of the two, but I think that would miss the bigger point.

IMO, the larger and longer-term problem is that (open source) version control systems seem to be mostly stuck in the early aughts. This may sound provocative, but in principle, Git and Mercurial don't offer much that wasn't already part of Monotone. Meta/Facebook has really been the only actor I am aware of who has been really pushing the envelope in terms of making open source version control more convenient.

If you think I'm being needlessly provocative, just consider this simple example: why don't version control systems (especially ones that can change history) have undo/redo functionality out of the box? I've only seen this as a Facebook extension for Mercurial that never made it into the Mercurial proper (and survived only as part of Sapling).

This is an essential feature of every basic editor nowadays and it is not easy to implement for a VCS, but it's still mind-boggling that after nearly two decades, it isn't considered core functionality of a VCS. Recovering from mistakes remains a pain point in pretty much any VCS, but shouldn't be.

Commit graph visualization is another problem that's just not handled very well by either Git or Mercurial and hasn't really improved much since their early incarnations, if at all. "git log --graph" or "hg log -G" don't really produce output fit for human consumption if you have even a moderately complex branch structure.

Version control systems are still generally very low-level, giving you a lot of primitives and very few high-level operations that aim at making complex workflows less complex.

I know people who express similar feelings. Usually it is shorthand for "I would prefer stacked diffs" or similar.

Two blog posts I've seen people point at:

* https://mitchellh.com/writing/github-changesets

* https://jg.gg/2018/09/29/stacked-diffs-versus-pull-requests/

I once worked with a guy who hated Python. He also hated IntelliJ and did all of his programming in Eclipse. He hated MacOS and would only run old versions of Windows of Linux.

What I found was that he was just sensitive to change. It took him awhile to get comfortable with something but as soon as he did he would from then on resist any change. Anything that was different to what he was used to he hated.

In some sense, it makes sense. People should prefer processes over tools in many cases. If you have a process that works with one tool but doesn't work with a new tool then you might be better off sticking with the original tool. Broken processes can debilitate organizations.

When people say "I hate X" often what they are really saying is "I have a process to do Y that works for me but tool X makes that process too difficult". The problem is they just say "I hate X" so you never really hear about the process Y which provides the context.

One point: if you are re-reviewing, other platforms (e.g. Phabricator, Gerrit) have much more developed ways to compare changes relative to one another.

Bias warning: I created CodeApprove to give GitHub reviews a better UI.

GitHub PR review UI is … fine. But it has very little depth. Unlike an IDE it’s hard to grow into a power user of it. It seems to be optimized for simple reviews with 1-2 rounds of a few comments each.

When you do dozens of code reviews every week you want something more. You want something snappy and dense with keyboard shortcuts. You want something that draws your attention to where it’s needed and something that helps you ensure all your conversations reach resolution.

So there’s a lot of room for improvement and GitHub hasn’t shown much interest in improving this area. So 3p UIs are stepping in (Graphite, CodeApprove, Reviewable, etc)

One issue I was discussing with a colleague just the other day is that you cannot leave a comment on lines that are not "part of the diff" (changed or context), which is sometimes really useful for "see this thing over here".

See https://news.ycombinator.com/item?id=37836932 by a Mozilla employee

Most of the projects that dislike GitHub's review UI want the functional equivalent of `git range-diff`. Code review systems like Phabricator and Gerrit basically revolve around this as basis of thinking about diffs, their evolution, and how code review progresses.

You want to write 3 patches to a project, that are committed in series, based off of `X`

         A ---> B ---> C
    X---/

Let's say A cleans up some code, getting it ready for B; it is not mandatory but was just naturally done as part of the change; maybe it's 50 lines. B then adds 500 lines of new code to be reviewed. Finally, C integrates the new code from B; maybe you migrate something to use it, changing a few internal API calls. So C might be a diff of only 5 or 10 lines.

The code reviewer will want to start by reading A, and leaving comments on A. And so on for B, and so on for C. Let's say they leave code review comments on each commit. So now you have a set of things to do.

GitHub encourages you to add a new set of patches on top of the previous 3, so you might publish add commits on top:

         A ---> B ---> C --- > D ---> E ---> ...
    X---/

Where each change after C incrementally addresses review comments.

In contrast, tools like Gerrit and Phabricator say instead that you should publish new versions of A, B, and C, wholesale. So now we have a new series of 3 patches:

         A' ---> B' ---> C'
    X---/

This branch might exist in parallel to your old one. So your full commit graph might look like this, now:

           A  ---> B  ---> C
          /
         /-A' ---> B' ---> C'
    X---/

So there's the original series of changes A,B,C, and the new series of changes that respond to all the comments. Think of that as "version 1" of the series and then "version 2"

Now here's the question: how does the code reviewer know that you addressed their comments? Answer: they need to do a range diff between the original version 1 series and the version 2 series:

    A  ---> B  ---> C
    |       |       |
  d(A,A') d(B,B') d(C,C')
    |       |       |
    A' ---> B' ---> C'

Where d(x,y) = diff(x,y). You're looking at the diff between the two versions of one patch. So instead you view the changes between version 1 of A, and version 2 of A. And so on and so forth for all 3 patches.

This is very useful for example because B might be 500 lines, but responding to review comments may only take 50 lines of fixes. It would be very annoying to re-read the entire 500 line patch, as opposed to just the 50 line incremental patch. This has very big effects as the review cycle goes forth.

People mostly like this review style because it keeps needless "fix review comment" commits out of the history and it "localizes" the unit of code review to each individual patch rather than the whole aggregate. Note that the final version of the series A,B,C will just contain those 3 logical changes, not 3 logical changes + 1 dozen fixup changes.

This not only makes changes more "dense", it improves the ability to navigate the history, and do things like `git blame`; and it means you don't commit things like "fix failing test" which would break bisection.

Note that most of the systems that implement the above review style do not literally use `git range-diff` in their implementation; rather, git range-diff is simply an implementation of this idea that you should review each version of a patch as a diff from the previous version. The tools themselves have their own lifecycle, patch management, APIs, etc that are wholly different from Git's.

Finally, there are lots of things GitHub's UX is just slacking on, functionality aside. You can't comment "anywhere" in a code review, just on changed lines. An annoying one I hate is that you can batch review comments but not batch review resolutions; if you leave 5 comments on a diff, you submit them as a batch. But if you resolve 5 comments, you do it one at a time, which is annoying and easy to lose track of. The UX has too many tabs you have to swap between, which is pointless when you could just make the page a little longer and things like Ctrl+F would work better. And so on, and so forth.

Github review is good for either zero or one round of comments. After that you can't tell what the hell is going on. It has clearly been written by people who do not themselves practice code review. Compare and contrast with Gerrit, which remains usable after many rounds of comments, in both directions, and changes. Compare also Phabricator.

bitbucket is worse, reviewees can resolve reviewer's comments (github has this too turns out), after file changes, comments disappear

The last update is from 2018. Did they give up?

Git won a long long time ago. Most people’s first VCS is now git. Mercurial is a lot better than SVN so it was able to pick up users back when SVN was dominant, but it’s not really better or worse than git it’s just down to taste. When you consider the network effects and switching costs it’s hard to convince anyone that mercurial is worth learning.

You'd need some arguments for the assertion that mercurial is better. I think Mozilla is switching because of years of failing to come up with good arguments. And it looks like they gave it a lot of thought. That and an increasing dependence on git internally to the point where people were spending non trivial amounts of time engineering around mercurial and coming up with all sorts of hacks to enable git usage. At least, that's what the article suggests actually happened.

You'll never get consensus on X being better than Y in the tech world. There are always going to be people that insist Y is better than X. And more power to them. But you have to be realistic. There is a lot of stuff that just never gets a lot of traction. Mercurial is one of those things. It's like betamax vs. vhs.

Initially it looked promising and then Github happened and the rest is history. The whole industry now runs on Git and Mercurial sort of flat lined in terms of growth after Github started hosting essentially the entirety of the OSS world (with few but notable exceptions of course). At this point it's a hard sell for new projects and some of the larger remaining users are switching away or are considering it.

Writing the article unlocked some traumatic memories of arch.

I liked bzr because it had simple to understand “versions” I could abuse to use like a single source of truth. Git requires manually applying tags to imitate it.