Git is ubiquitous, there's no really important feature set that hg offers over git, and it's super trivial to convert repos from hg -> git. So why go through this effort?
Note: I'm not trying to start a flamewar; genuinely curious.
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.
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.
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.
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.
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.
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
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?
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...
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.
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.
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.
People who've not used git and come to mercurial don't find anything wanting in it.
Now that bitbucket support is gone, I agree it's not worth the effort unless it's already deeply integrated into your tools.
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.
Also big companies such as Facebook and Google use it because it's more extensible.
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.
Either way, they're both pretty similar at a high level and work great.