[eire1130]

I wanted to respond to this thread in general as someone who runs a team that uses Mercurial for most of our work.

But first, the proposal above, in my view, isn’t core mercurial, which is what most of this discussion is centered around. This is mercurial with evolve + topics, which has differences to what many of you are familiar with.

With evolve + topics, many of the critiques of mercurial go away:

  * Light weight branches for short development
  * Ability to squash / fold - mutability
  * Ability to rebase - mutability

With this class of features, you get the major product differentiator that git offers (light weight branches that are simple for collaboration). Therefor, if you value some of mercurials core features, and your primary value from git is the light weight branching model, mercurial with evolve + topics starts to look like a real solution for many shops.

That is why this proposal is important and stands out from bitbuckets offering. Bitbucket (For now) only offers first class evolve support (in beta).

With that said, we use mercurial in production for our main repository. We do use evolve + topics for our development and when commits land in production, those commits become “immutable”. Topics were very much a game changer for us when we started using them about a year ago. We had previously used bookmarks for collaboration and that situation wasn’t really viable.

Like most people reading this here, our development team targets mostly web development. Most of our dev lives in one repo and generally we target a deploy per day, or multiple per day. We aren’t “continuous delivery”, but we are “effectively” “continuous delivery”.

We have a straight forward workflow. We have a Topic per Jira ticket. That Topic gets cut from the head of the branch “default”. Developers work in these "feature branch" through the features lifecycle, sometimes these are big things (multiple week - big changes) and sometimes small things (hours or days worth of work). Developers can rebase their work, if they wish, and they can squash, if they wish. I generally discourage the later as I’m a believer more commits the merrier. I’m also not allergic to merging and I don’t see the value in a purely linear history, so rebasing isn’t as common for us. We also have a single integration branch. When developers are ready, we merge to this branch and the ticket gets advanced to qa. Once the ticket passes qa, we merge to default (therefore advancing the head) and the topic is closed out on its own.

So with the above as a brief overview of our process and workflow, I wanted to also talk about some of the pain points that mercurial has. Some of these aren’t necessarily caused by mercurial directly, and some aren’t even addressable (ie, if we were to switch to git, we’d have the same problems, or similar)

Pain Points:

  * Tooling kind of sucks. The biggest argument now to use git is less git itself, and more that you are buying into an ecosystem. As an example, we use Buildkite for our CI. Getting this started required some hacking to make it work. Buildkite doesn’t “just work” with HG. That’s generally the tooling story. We can make some stuff work, but most stuff doesn’t “just work”.
  * Merges can occasionally still be painful in a collaborative environment when multiple devs are touching the same files and the same line numbers. I think this is an unsolved problem and probably will remain so until the universe cools to absolute zero.
  * Evolve is great and I use it all the time, but some of developers here complain that it isn’t as well documented as other pieces of mercurial.

Benefits:

  * In my view, the UI is simpler. Our team is comprised of individuals of varying degrees of technical sophistication. For examples, our designers are not software engineers and don’t really need to understand what a DAG is. But they do need to commit directly to our repository, create topics without asking others, and really only ask for help when they did something wrong / got themselves in trouble
  * TortoiseHG. This is a great tool, and most people can get benefit from it. It has some support for topics.
  * All commits are kept for all time. Not everyone finds this valuable. I find this extremely valuable. Evolve handles the mutability question by “hiding” old commits and basically creating new ones.
  * Hg log, which was mentioned before as a burden, in my view is a huge benefit and feature. Most hg commands take a revset.

[yes_or_gnome]

Your comment is criminally low. Every other comment is 'Git vs. Mercurial' and speculation as to why git has "won". Their not useless, but they are uninteresting technically. So, as a git aficionado, I thank you for a detailed analysis of Mercurial and this proposal.

Personally, I've only used Mercurial to check out some projects that use it exclusively (i.e. (previously) Python and Firefox) and to create a toy repo of no significance (to learn its CLI interface).

Just to highlight a couple things from your comment:

> Therefor, if you value some of mercurials core features, and your primary value from git is the light weight branching model, mercurial with evolve + topics starts to look like a real solution for many shops.

By far the most annoying thing about going from git to mercurial is the overloaded concept of a 'branch'. I couldn't care less about the continued existence of my one-off, topic branch. TBH, I prefer the git concept of the reference pointer being culled in the process. The (git) branch's existence continues on only in the merge commit message. Although this assumes 1) an actual merge was committed (not rebased), 2) the merge wasn't fast-forwarded (--no-ff), and 3) the default merge message format was used.

> With that said, we use mercurial in production for our main repository. We do use evolve + topics for our development and when commits land in production, those commits become “immutable”.

> Developers can rebase their work, if they wish, and they can squash, if they wish. I generally discourage the later as I’m a believer more commits the merrier. I’m also not allergic to merging and I don’t see the value in a purely linear history, so rebasing isn’t as common for us. We also have a single integration branch. When developers are ready, we merge to this branch and the ticket gets advanced to qa. Once the ticket passes qa, we merge to default (therefore advancing the head) and the topic is closed out on its own.

We use Github. IMO, Github made a HUGE mistake when they added the options to Rebase and Squash in-lieu of the only sane option, Merge. I suspect that a lot of users wanted these options because Github (still) refuses to drop the --no-ff from their Merge strategy. I prefer --no-ff, but I do agree that it does make for an ugly log graph; Unlike most people, I couldn't care less about pretty graphs.) Rebase and Squash shouldn't be considered "Merge" strategies. They're for cleanliness, but only prior to sharing changes. Having them in Github has made the process of figuring out what has (and hasn't) been merged just absolutely atrocious. I'll leave it at that, but needless to say my arguments haven't convinced my peers' desire for pretty graphs.

As far as other user comments, I think the most egregious suggestion has been (paraphrasing):

> Mercurial has (had) better documentation.

Which I think is patently false. Git' manpages are (and always have been) fantastic. git-scm.com has been around for as long as I can remember. If you really want to do so, you can get yourself deep into the git's technical documentation which will teach you everything about the file formats and algorithms that are being used. All of this documentation has been around since git maintenance was handed over to Junio Hamano (circa May, 2005); Long before it's popularity explosion.