One of the first things I did was switch us to git.

Mercurial was way easier to use and fit our use case but all the tooling was built for git.

20 years ago, Mercurial was not the wrong choice.

- Its internal design was very similar to Git's.

- Its cross-platform support was superior to Git's. (Git didn't get good Windows support until some years later.)

- Its ergonomics were superior to Git's, which was an important factor on its own, and especially important when trying to get a whole organization to retrain and retool around a distributed model.

- (It had a third major advantage over Git that I unfortunately cannot recall at the moment.)

So you weren't wrong back then...

...but Git improved over time, tipping the scale closer to a balanced state. It also had unbeatable author recognition, making it the obvious choice for anyone unaware of Mercurial's advantages, and eventually leading it to benefit from the network effect. And GitHub appeared, greatly improving Git's ecosystem with no support for Mercurial.

Git has so many gotchas, bells and whistles that whenever I'm doing something out of the ordinary I'm wondering if there isn't an easier / canonical / smarter way I should be doing it.

[1] https://repo.mercurial-scm.org/hg-stable/rev/d4ba4d51f85f

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

(Hopefully this comes across as curious, which it is, and not antagonistic, which its not)

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.

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.

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

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.

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.

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.

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)

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!

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.

If git doesn't let you do them "right", your concept if "right" is wrong.

People always say you have to know git internals in order to use it, but that's just not true. Git has the right data model and has always been about empowering users to edit their data. Which makes the data model be "in your face" compared to the alternatives (and I think that's what people latch on to when they talk about "internals"), but it ultimately makes for a better tool.

And then, when you pull someone else’s in-progress work to inspect it, you end up with their branches showing up with their names and you ended up with revisions 13564-13592 belonging to someone else and showing up in your history graph even when you continue on your own work at revisions 13563 and 13593. I ended up using temporary clones and strip a lot.

git branches, in contrast, are delightfully unobtrusive.

I started with Mercurial, eventually got forced into git, and now use jujutsu.

Totally agree with the Mercurial developers: Just use a branch/bookmark. When I encountered it in git, it seemed neat, but became yet another concept/thing to clean up that you don't need to.

And lo and behold, after switching to jujutsu, everyone shows how you can do a stash using an (anonymous) branch.

Even though I used stash a lot in my git days, I don't miss it at all while using jujutsu. The benefit of jj is the ease with which one makes branches (without needing to name them). That's why you may not have liked the advice in mercurial - it wasn't the solution that was problematic, but that mercurial didn't make it as easy as it should have been.

(Same goes for index - no one misses it once they switch to jujutsu).

TortoiseHG is a very good client that covers all common Mercurial operations and then some. It's on par with a couple of commercial git clients that I've used. On the server side, there's e.g. heptapod as a GitLab fork that has a deep Mercurial implementation.

It means that git invented a bunch of new jargon and ideas that confuses people exposed to it for the first time, where hg's usage metaphor hews closer to the received wisdom of people coming from stuff like subversion and perforce.

It's true that git's ad hoc command line UI isn't exactly it's greatest strength. But given the complexity of the design space here that's a pretty weak argument IMHO. The two weeks it takes to get the basic git workflow into your muscle memory pale in comparison to the years it'll take you to be good at bisection and tree maintainership.

It's also sort of a wrong argument in the modern world. People new to git have extensive assistive technologies available. There is, after all, no HgHub out there.

That said, if/when stacked PRs become a first-class citizen in GitHub, more projects will see the benefit of this approach (though they'll probably mostly get there through squash-merges).

The plugins were usually shipped with mercurial so you didn't have to install them separately, but you needed to know that you had to enable them in a config. And I beleive this turned a lot of people off.

I think some of the extensions were very basic stuff like graph logging and colorized output -- and mq like you said. So it was kind of unfortunate that people got a bad impression of hg from that and bounced off.

For a complicated long running feature branch I can see it. Instead of repeatedly merging the root in during development it can be cleaner. Tools aren’t always good at figuring out in a PR what was written and what was caused by those merges from root. And history looks better at the end.

For a short branch that can merge cleanly or perhaps very close to it, I’d kind of rather have the ‘true’ history. I don’t think it’s worth it.

I’ve never understood the “everything must be rebased before every merge” desire.

Finally, in one team, I more or less forced a senior engineer use merge (or rather, I was in control of the project and did not force other developers to use rebase). After a year, he admitted that he no longer really saw a benefit in rebase and switched to just using merges in his own projects. He also noticed fewer merge conflicts this way.

"For a complicated long running feature branch" always simpler to repeatedly merge main into dev, easier conflicts solving etc

For simpler cases squash+rebase as default merge strategy trumps leaves a nice clean history.

Show a diff: svn diff / git diff

Show log with diffs: svn log --diff / git log --patch

Git calling the same or similar things different (or just terrible - tree-ish? ref?) names is one of the worst things about Git.

[1]: https://mercurial-scm.org/help/commands/serve

Mercurial's "branch" was generally intended for long-lived things. Think the "stable branch" or a "version X" support branch for a project.

The branch name is baked into the commits that use it. You can hide them from the UI with "--close-branch", but they will still exist forever in the commit history. This is both a good thing and a bad thing, depending on your desires.

This is different from Git's "branch" which is basically just a pointer to a commit. It is not part of commit history, it is just a convenience for the developer. Later, Mercurial added "bookmarks" which are similar.