
Adding Mercurial support to Gitlab - testcross
https://gitlab.com/gitlab-org/gitlab-ce/issues/31600#note_96793407
======
maxxxxx
I still don't understand why git became so popular in comparison to Mercurial.
Mercurial seems like a much more friendly and sane system. I hope adding it to
Gitlab will help its popularity.

~~~
JoshTriplett
Speaking as someone who used both Git and Mercurial, and who has used both to
contribute to projects:

Git's concept of branches as simple names for commits, and the ability to
switch branches really easily within _one_ checkout (rather than encouraging
the use of multiple working directories) helped hugely. Mercurial grew the
ability to do git-style branching later, but git had it from the beginning.

Git has _always_ treated performance as a first-class feature, and that has
enabled certain types of workflows that Mercurial makes painful. Git is fast
enough that many things don't feel like they take any time at all.

Git integrated first-class support for carefully constructing and reworking a
set of patches to be sent by email. Mercurial again eventually grew such
support, but early on, it was much more insistent that all branches must be
kept around, and by the way are you sure you don't want to push your
development branch experiments up to the server and keep them there forever
since you haven't merged that head into the mainline?

Even later on, mercurial had more of the functionality people wanted but
relegated it to "extensions", while Git shipped it out of the box.

Take a look at [https://walac.github.io/mercurial-for-git-
lovers/](https://walac.github.io/mercurial-for-git-lovers/) (from 2015) for
just one of many examples.

~~~
quietbritishjim
> Git's ... ability to switch branches really easily within one checkout
> (rather than encouraging the use of multiple working directories)

As a heavy Mercurial user, but only for the last couple of years, I'm confused
by this one. You can just as easily switch between branches (in the Mercurial
sense) and bookmarks (which are Mercurial's name for Git-style branches). How
did that used to be different?

In fact one of the nice thing about Mercurial is that you can easily switch to
_any_ commit and you don't need to choose between a hard reset and a detached
head, because you can always make a commit anywhere (multiple heads for the
same branch) and it will never get garbage collected (a foreign concept in
Mercurial). Mostly this is good because you simply never need to understand
what these concepts mean, which it turns out are not fundamental to DVCSs. But
also this makes a neater alternative to stash (although stash is also
available): just commit your half-finished changes, mark the revision "secret"
(which means it won't be included in any push), then switch to another
revision. You can always strip or rebase the revision later, so long as you
haven't pushed it (admittedly these actions do require extensions, but they're
included with all Mercurial installations).

~~~
ygra
Our workflow at work (with Mercurial) revolves heavily around multiple heads
for a single branch and relating the commits to a JIRA issue is done by simply
putting the issue number in the commit message. So we have (unnamed) feature
branches and also no bookmarks for them. You just start from the latest
release tag and create new commits. No need to think of a name for the feature
branch, or telling the reviewer or issue tracker which bookmark belongs to
that issue.

This might be mainly habit and familiarity with a different tool by now, but
to me it's simpler than equivalent Git workflows as there's less ceremony
involved to start working and there's no fear around accidentally losing
commits because they don't belong to a branch (I kinda hate having to go into
the Git reflog to find commits that are temporarily lost because they don't
belong to a branch).

~~~
bmurphy1976
Well that is just about the strangest workflow I've heard of. It sure seems
like you are throwing away a lot of the power of the tools to do things
manually. Honestly, I don't see the point.

I've used Mercurial from the very beginning, the branches are great and
bookmarks are fine. I see no reason why you wouldn't use them.

~~~
ygra
We use both, just not in the way a typical git workflow would use feature
branches. Basically those are all anonymous heads on the same branch for us; a
workflow that is probably as alien to git users as naming each and every head
is to Mercurial users.

------
erlend_sh
For a strong contender to "next-gen DVCS", I recommend checking out
[https://pijul.org/](https://pijul.org/).

Written in Rust and based on a sound theory of patches. If GitLab actually
merges Mercurial, I sincerely hope Pijul is next.

~~~
simias
Pijul looks very interesting but unfortunately as it stands (and without a
huge open source project à la Linux to back it) I can't really imagine it
taking over git as it stands. It might be better than git but is it enough an
improvement to justify the cost of switching? I'm not sure.

Now if pijul takes inspiration from Fossil and implements things like issue
tracking as part of the DCVS then that would be an other story as far as I'm
concerned. That would be a pretty radical upgrade from git.

~~~
epicide
> is it enough an improvement to justify the cost of switching?

This is the main question everybody should be asking about potential
contenders [0].

For most places, switching would be a huge undertaking. Even if there's an
import tool that works flawlessly (big assumption), you now have to
potentially re-think all of your secondary tooling [1]. Not just 3rd party
tools, either. You have to think about potentially tweaking build pipelines,
etc.

Not to mention (re)training people which is very likely orders of magnitude
more costly [2].

For any potential tool to overtake git, it will have to provide some pretty
extreme benefits. Git originally provided some pretty extreme benefits over
SVN and yet there are plenty of places that still can't justify the cost of
even making _that_ switch.

[0]: I'm only talking about contenders for large projects and/or business'
ecosystems. Use whatever you want on your side projects.

[1]: GitLab adding support for alternatives is a good way to start mitigating
this.

[2]: In more ways than just purely financial.

~~~
davemp
Heck there are places that use ClearCase still.

Companies that are at rest tend to stay at rest.

------
Annatar
Mercurial is much easier to understand and use than git, and _for the most
part_ has feature parity with it. The only drawback was the decision to
implement it in Python, which makes it very slow for large codebases with
gigabytes in binary files. However, I'm given to understand that core
performance parts are being re-implemented in C.

~~~
dymk
What's interesting is that Git is fast up until it isn't, and it's written in
such a way that fixing performance issues that do pop up is hard (or extend
the software when more custom behavior is needed).

That's why Facebook chose to just fix the slow parts of hg[1], rather than fix
the slow parts of git, to build a VCS which would scale with its codebase.

[1]: [https://code.fb.com/core-data/scaling-mercurial-at-
facebook/](https://code.fb.com/core-data/scaling-mercurial-at-facebook/)

~~~
whyever
> That's why Facebook chose to just fix the slow parts of hg[1], rather than
> fix the slow parts of git, to build a VCS which would scale with its
> codebase.

On the other hand, Google seems to successfully use Git in the same way.

~~~
jhasse
Or Microsoft (Windows is using Git).

~~~
pjmlp
With extensions to make it bearable for their code size.

~~~
jhasse
Just as Facebook does for Hg: [https://bitbucket.org/facebook/hg-
experimental](https://bitbucket.org/facebook/hg-experimental)

------
kjeetgill
Hm. My understanding is that the git and mercurial worlds follow different
workflows around branching, merging, forking, etc.

Does that cause a huge impedence mismatch in the UI? Or will they converge?

In the same vein, I wounder if it's possible for a single repo/history to be
checked out with either tool. You clone with hg, I'll use git. We both merge
with patches as a common language.

Disclaimer: only use git

~~~
y4mi
bitbucket supports both as well

------
marcinkuzminski
For a self-hosted option please check out RhodeCode has the first-class
support of Mercurial, including largefiles, evolve, phases etc.

~~~
alwillis
Kallithea is fork of RhodeCode, fully supports Mercurial and Git and is open
source: [https://kallithea-scm.org](https://kallithea-scm.org).

~~~
marcinkuzminski
RhodeCode is open-source too and unfortunately looks like Kallithea is a dead
project by now. It didn't have a feature release since 2015, only a few
bugfixes.

------
testcross
I read a few articles about a new way to work with hg that appeared in the
past few years. They were saying that we don't need to have names on every
branch. That actually we don't need to name many things and it works much more
smoothly. I wonder what is the opinion of hg users here.

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

------
julia_lang
Off-topic, but I think GitLab has incredible good (fast) marketing. If there's
any inconvenience their CEO and his minions are there like in a second.

Are there specific tools for that?

------
sras-me
Glad to hear this. I hope one day I can go back to Mercurial without the fear
of being singled out.

------
MordodeMaru
Who other than FB albeit customized is using Mercurial in prod?

~~~
alwillis
Mozilla.

~~~
MordodeMaru
Really?

~~~
alwillis
Yes: [https://mozilla-version-control-
tools.readthedocs.io/en/late...](https://mozilla-version-control-
tools.readthedocs.io/en/latest/hgmozilla/index.html)

------
_jezell_
Nice to see someone finally do this. I love the Gitlab team.

~~~
jahlove
as i read it they're not doing it

------
Walkman
It's GitLab, not MercurialLab. Hope they realize this and refuse to merge. I
really like shared tooling and knowledge, so if Git dominates everywhere, all
you have to do is learn git and that's it. It's a significant overhead to
learn yet another VCS just because it is a little nicer. I hate wasted
efforts.

~~~
hvidgaard
Do you really want a dev environment where there is only one way of doing
things?

~~~
Walkman
Yes! Absolutely! So I can focus on innovating where it matters (the product
I'm developing). It alao would mean those things would be extremely polished
(because a lot of people affected and interested to make it good). Also I
would not need to learn so much random stuff I don't really care about.

~~~
BeetleB
In my experience, every time I've encountered someone who has this point of
view, what they really mean is "Yes, we should have one way to do it, and it
should be the way _I_ like".

The obvious counterpoint to your statement is that if your mentality held
sway, we would never have had Git and would still be on SVN.

~~~
Walkman
I'm not saying this because of my rigid opinion, but because of productivity.
I WISH Mercurial was the one who caught on, because everyone says it's better,
more intuitive (oh, and it's written in Python which I absolutely love) but
this is not the case, Git won and people should accept that.

To put another way; I HATE git, I LOVE Mercurial, but Git won, it's ubiquitous
and Mercurial is not that much better.

------
krob
Oh the irony, phabricator has had mercurial support since day one almost.

~~~
mappu
I evaluated phabricator today for Hg hosting at $DAYJOB. Issues in Maniphest
aren't "attached" to a Diffusion repo, so you can't use it as a Gitea/Github-
style one-repo-one-project system; it's one-phabricator-one-project-multi-
repos. Spaces help a little bit but not really.

Dealbreaker for us - we'd rather retrain staff on hg->git (and lose the
amazing TortoiseHg).

