Mercurial is great at an org with lots of junior devs, because people really have to try hard to mess things up compared to git. It's very bad if you want to attract people who feel comfortable with git alone (despite the fact that they'd do quite OK with hg), and it's especially bad if you are trying to fit with very standard types of CI, which for the most part have close to no support for mercurial at one point or another in the chain. And you might find that out a bit late into the process and end up paying a steep price ("Hello Gitlab? yeah I'm gonna have to set up a local secured Jenkins instance to do this and that before sending you the rest" type of thing)

Recent-ish stackoverflow survey (2-3 years ago) also indicated that hg is used even less than zip files amongst devs, and significantly less than git, so market adoption is a big hurdle and anybody joining you will have to deal with this-thing-they-probably-don't-know and tooling that might not handle it (e.g. Xcode).

However I think there's value in hg being training-wheels for git and a safe haven for a bunch of newbie devs, and we're talking about people who know and enjoy tech here so using any kind of vcs will at the very least enable your team to open up to more stuff. There's plenty of tooling and support to migrate to git if/when necessary, and IMHO Mercurial gets a much worse rep than it actually deserves.

As someone who only knows Git, needing to work on an open source project where you had no choice but to use Mercurial was a massive pain. I don't remember what happened exactly but coming from Git I managed to accidentally make a change somewhere but later needed to pull the latest changes and couldn't figure out the equivalent of rebasing and, when I got fed up with that, hard resetting for an hour. In the end I gave up and used git-hg to fork the repository, losing the ability to merge upstream, because I wanted to get things done and did not want the requirement to learn an entirely new VCS just for this one repository to hold me back.

But that's coming from me, who doesn't understand how Mercurial is supposed to be used. I felt happy when BitBucket announced they were sunsetting Mercurial, because of the miserable experience I had with that one single time and the fact that it would mean that all of the repository owners who forced you to learn Mercurial to contribute to their code would have no choice but to switch their repos to Git. But because I don't know any better I guess I don't understand what was being lost fully by losing Mercurial.

It's quite valid. I think the biggest hurdle is noticing that when you mess up hard with git the hurdles are affecting everyone down the line, possibly irreversibly. If you mess up with mercurial, the hurdles are affecting YOU locally really hard, possibly irreversibly.

That's probably why it's the main reason git people hate hg and hg people are confused about git, until they really mess up, and outside people view hg as much more limited than git.

I don't really have a side in any metaphorical battle because I've had to set up CI/CD for a mix of git and mercurial, but simply giving in to the social pressure of the tech world I've become more acquainted with git over time than with hg as a junior and I can see value in both.

However at a higher level (organization level especially), it's critically important to look at the trade-off that the choice gives you.

I'm trying to be objective here in saying that unless mercurial gains more traction in the world, fortunately or unfortunately you should stick heavily with git.

It. Just. Works.

The only people who are unhappy with Mercurial are git users. Everyone I know who is coming from something else to Mercurial never have a desire to leave it.

It has a lot (most, really) of the power of Git, but no one has found a need to make an "Oh Shit Hg" site, because it's not trivial to screw up in it.

Because it has a separation between simple and advanced features (many of which are disabled unless you explicitly enable them), you don't get people wasting a lot of time trying to find the ideal workflow in Mercurial. In a sense it's a bit like Perl vs Python. Perl has many ways to do the same thing. Python is more opinionated, and has preferred ways of doing things. As a result, a team of N Mercurial users will usually not have N different workflows. In my current team, there's been a lot of thrash/arguments over the workflow (rebase vs merge, squash vs not, linear vs branched history, history rewriting vs not, etc).

The documentation, though, sucks. It's quite outdated.

Can someone actually mention the positive side of Mercurial specifically?

I'm getting bit by git so often and for those people who are barely programmers are also required to use git to commit their HTML/CSS stuff but once something doesn't work, I have to Google around and waste an hour trying to fix the repo and I'm all for willing to use something else if it's better but I know that people just simply jumped on it because of Linux/Linus name without thinking (kernel workflows are different than most people's but people only realized after feeling the pains) and the git's ecosystem is already far ahead of the others.

I even considered using subversion locally to push to central git but there is no such luck when the reverse is quite possible.

> Can someone actually mention the positive side of Mercurial specifically?

The workflow is faster for new users to learn, less concepts to grok, good GUI support, that's about it

> and for those people who are barely programmers are also required to use git to commit their HTML/CSS stuff but once something doesn't work

You would find that it's difficult to get non programmers to use hg even with a GUI, unless you have some very open minded people

> I know that people just simply jumped on it because of Linux/Linus name without thinking

Not true, so many git users have no idea who made this tool and don't actually care, all they care is that it's open source and suits most of their tasks

New users don't know but early adopters who advocated to spread the ecosystem and tooling surely chose git because it was used for the kernel and guessed that it would work for everyone. New users never had any choice these days as their workplace is already using git.

> you don't get people wasting a lot of time trying to find the ideal workflow in Mercurial.

Interesting. I’m keen on trying Mercurial, but one thing that has somewhat confused me is the profusion of branch-like workflows. Named branches, bookmarks, now also topics (or whatever it’s called), hidden commits etc.

Is there a good definitive guide somewhere on the best workflows for hg?

> Is there a good definitive guide somewhere on the best workflows for hg?

I don't know about workflows specifically, but there is a very good reference [0] about Mercurial's branching models. Maybe this will help you.

[0] https://stevelosh.com/blog/2009/08/a-guide-to-branching-in-m...

Thanks for this. This is fairly old now though, and doesn't even mention bookmarks (which I understand to be like git branches, except they aren't (?) synched between repo copies. Then there's some new stuff that apparently are very good, but I can't find a proper description of how they work / should be used.

> This is fairly old now though, and doesn't even mention bookmarks.

What do you mean? It has a section on it:

https://stevelosh.com/blog/2009/08/a-guide-to-branching-in-m...

(I have not audited to see how accurate the information is, though).

> Then there's some new stuff that apparently are very good, but I can't find a proper description of how they work / should be used.

Yes - I often wished that someone wrote and maintained an article listing all the extensions that one likely will want to use.[1] One you may want to look into is evolve.

[1] Maybe someone has written this - I haven't checked in the last few years.

Ah my bad, missed it, you’re right.

That's what I meant by outdated documentation.

I personally use bookmarks. They're simple to use. However, people have issues using them in a team setting (by default it doesn't sync the bookmarks when there's a push, I think). I have not explored topics - looking at Heptapod it seems they prefer topics, so it may be the way to go.

If you're the only developer, then bookmarks should do everything you want.

I'm reserving judgement on HG but the comments saying it just works and is so easy gives me a good chuckle were I've had to set up all sorts that's non-obvious. topics not branches? cool ok. command not found, right uh enable extension 'topics =' yep sure obvious ok, Huh wired error now. oh pip install hg-evolve has topics in it fine ok.

go add a remote to an existing repo. lovely ux there.

and now you're telling me about bookmarks, I've a docs page open to read about phases, that seems kinda neat. at first glance thought it seems like a solved problem of protected branches and separate forks.

As I said - the only people who complain are those who are git users :-)

People who've not used git and come to mercurial don't find anything wanting in it.

I find it more intuitive than git. I think it's especially easier to move, split or combine repos, but others will disagree. We used to use it at my company, but at a certain point, it had to be a forced effort to use as opposed to git, which is the default for most tools and incoming engineers.

Now that bitbucket support is gone, I agree it's not worth the effort unless it's already deeply integrated into your tools.

There's no reason not to use Mercurial. It's version control software. If you like it, use it. It's that simple.

Version control is one of those things where a lot of the value comes from using what other people use.

By definition, version control is for collaboration, so using a less well-known version control system impedes the regular work of your project.

There's also the issue that version control is integrated into lots of other software. Everything now supports Git and Subversion, but support for other VCSes is rarer.

This is kind of unfortunate, because it makes innovation hard. Projects like pijul exist to try to move the state of the art forward, but it's difficult to see how they will gain adoption.

Yeah but I like Gitea and it doesn't support Mercurial. How can I just use it?

Mercurial is much more user friendly.

Also big companies such as Facebook and Google use it because it's more extensible.

Facebook and Google may use it but it serves, more or less, as a front-end to something else. Especially at Google, where it is optional to use Mercurial at all.

To me as a daily Mercurial user, the biggest thing it brings is, in Git parlance, a distributed reflog. It makes sharing of mutable history much easier and safer.

Mercurial has the concept of changeset evolution [1] that tracks the meta-history of changesets (commits): who re-wrote which commits at when using what command. Stored as obsolescence markers in the obstore, this meta-history is synchronised with remote repositories on pull and push.

[1]: https://www.mercurial-scm.org/wiki/ChangesetEvolution

Combined with a nice history rewriting UI provided by the evolve extension [2], this allows some advanced collaborative workflows that are pretty awkward in Git.

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

Suppose you developed feature x on branch [3] feature-x, and submitted it for review. At the same time, you started developing feature y that depends on feature-x on branch feature-y. When feature-x is integrated to master via a rebase, you can run `hg pull` and `hg evolve`, and Mercurial will automatically rebase feature-y on top of master. This also works when commits are edited, squashed, split, reordered, or dropped. This gives reviewers more freedom to decide what to accept, without having to worry disturbing contributors' work.

[3]: Using Git parlance to simplify things. Branches meaning something else in Mercurial.

Now you've also pushed feature-y. This time the reviewer wants you to change something. You changed the commits, and pushed feature-y again. Even without force push, the server will not reject the push, because it knows from the obsolescence marker that the new commits are not really new but are re-written old commits. Again, this even works when commits are rebased, squashed, split, reordered, or dropped.

While there is no commitment yet, now that Mercurial is gaining the ability to operate on Git repositories, there are discussions on how to store obslog in Git's store, so maybe that's something that Git will eventually have.

Another thing I like very much is that every commit in Mercurial is a standalone ref. This makes a patch-based workflow a lot simpler as you don't need the ceremony of creating and cleaning up branches. You also don't run into detached heads.

I prefer mercurial over git. The workflow and branching/merge process is a whole lot more intuitive to me. Git seems to have a million commands each with a unique set of args that can do very thing things.

Either way, they're both pretty similar at a high level and work great.

iIUC Mercurial is better for managing very large repos because it supports partial checkout. This large companies with monorepos are more likely to choose mercurial. Of course there are ways to modularize a large codebase in Git (submodules, Android's repo system) but they tend to be clunky and inconvenient.

Wow the number of typos in this comment. I shouldn't type on a broken screen.

I haven't used it in a while and forgot about that very nice feature!