
Mercurial: Onward and upward - gitdude
https://blog.bitbucket.org/2015/04/30/mercurial-onward-and-upward/
======
sergiotapia
Key paragraph for us mere mortals:

"In my time with Mercurial, I have seen it grow in fascinating ways. These
include the concept of changeset evolution coming to life and the announcement
of both Facebook and Google choosing Mercurial over Git. The future of
Mercurial is that of scalability and because of that, I believe the best days
of Mercurial are ahead."

Is it time to give Mercurial another shot? I first migrated from SVN to
Mercurial way back when - but after the massive increase in Git's popularity I
bit the bullet and switched.

What does Mercurial have over Git _today_?

~~~
sampo
> What does Mercurial have over Git _today_?

There exists no easy tutorial, that takes a beginner up to speed with git. You
need to read almost a book length of material and familiarize yourself with
some of the git's internals, and to some extent build your own mental model of
git by experimentation, before you can use git without regular wtf-moments.

Well, there is also no tutorial that would provide the same level of
understanding of the internals of Mercurial, but by some magic it seems that
beginners do not _need_ to acquire the same depth of understanding of
Mercurial that they need to acquire about git, before they can start to work
with Mercurial without wtf's and frustration.

Once you have a solid understanding of how DVCS's work, you can use both
Mercurial and git without problems. But if you need to bring a bunch of
beginners up to speed, somehow it goes easier with Mercurial.

At least, this is my experience. If someone else has experience in training
teams to start using a DVCS, and has compared both git and Mercurial, and has
opposite experiences, I'd be interested to hear.

~~~
Touche
I simply don't agree with this. There's nothing wtf about git add, git commit,
git push. Those are the commands that normal developers use. Maybe git reflog
has issues but 90% of people are never going to come across them.

~~~
worklogin
Nothing about that deals with collaboration.

fetch/merge/pull/remotes can be pretty confusing without really wrapping your
head around it.

~~~
Touche
What is wtf about git pull?

> git pull origin master

(fix conflicts)

> git commit

That's it.

~~~
dfabulich
1) Pull creates a merge commit. Why?

2) What's a fast forward?

3) What's a tracking branch?

~~~
somebehemoth
1) So you can revert the merge very easily. 2) Merging without a commit. 3) A
branch on a remote server that you have a copy of locally and you want to keep
track of the status of remote against the local copy (who's behind and who is
ahead?).

This is my basic understanding in terms of how I use git. I like Mercurial too
and don't have a horse in this race.

~~~
mpdehaan2
While this somewhat underscores some complexity in git, here's something I
wrote trying to explain to others why and how to avoid those merge commits:

[http://michaeldehaan.net/post/116465000577/understanding-
whe...](http://michaeldehaan.net/post/116465000577/understanding-when-to-use-
git-rebase)

------
krylon
Mercurial was a real eye-opener. Before a friend basically made me try
Mercurial, I was using Subversion for managing my private projects, and it was
not exactly fun. Especially when I was working on my laptop (netbook,
actually, but that is totally OT), away from home, without access to the
server.

Mercurial made VCS fun. I recently moved on to Fossil, because I do like the
integrated wiki and ticket system for smallish projects, but without Mercurial
I never would have gotten there.

I also like Mercurial's hooks. I am not sure if other DCVS support that, but
hooks are great. (Fossil doesn't appear to have them)

~~~
stevekemp
I agree that hooks are awesome, I use numerous hooks with git to do everything
from syntax check Perl scripts, to uploading DNS zones.

------
ngoldbaum
I'm excited to see improved mercurial support at bitbucket in the near future.
While bitbucket's support for mercurial goes back many years, mercurial itself
has evolved a lot in the meantime, and bitbucket has been focusing more on
support for git for several years now. At the very least, I'm glad they have
someone on staff who cares about mercurial so new features don't break things
for mercurial users.

------
kasabali
> The future of Mercurial is that of scalability and because of that, I
> believe the best days of Mercurial are ahead.

That sounded to me like Mercurial has started to carve their own niche after
losing the popularity war to git (maybe just my wishful thinking?), and this
may have very good outcomes since currently all scalable mainstream vcs
choices are centralized.

Git developers showed they're hardly interested in this area, and Mercurial
have had some head start with the contributions from Facebook. I don't think
anybody would object it if we had a free dvcs that can respond to very high
scalability needs without hacking around its deficiencies. This is the point
where Mercurial project should reconsider its priorities and even put some of
their current priorities into back seat if that's what it gets to achieve
their new goals with no compromises.

My best wishes for Mercurial, go for it!

------
krupan
I love all the new things the mercurial developers are willing to experiment
with and try out. It seems the (sometimes maligned) plugin system that
mercurial uses makes this easy. It's been really interesting to see how our
(mercurial developers' and users') ideas about how distributed version control
can and should be used have morphed and changed over the years. I remember
when mercurial's branching recommendation was to have a clone per branch and
when we all hated the idea of modifying our history. Now mercurial supports 4
different branching models and has excellent history editing support with
commit --amend, rebase, histedit, and changeset evolution. I'm excited to play
with the other new features that are coming.

------
j_baker
> These include the concept of changeset evolution coming to life and the
> announcement of both Facebook and Google choosing Mercurial over Git.

Perhaps this is true for Facebook. But I can say that Google most certainly
does not use Hg over Git. The Go source code used to be under Hg, but they've
recently migrated to git.

~~~
Mathiasdm
I'm guessing it depends from project to project? There are several Google
developers contributing to Mercurial.

~~~
cdibona
If you look at development at Google, you'll see most people on a perforce
derived repo system , then groups like Android, chrome, Etc on git, then
basically very few teams using Mercurial.

We do have some hg contributors like augie, but we have way more git
contributors, includes git project Lead Junio.

------
jordigh
I'm very excited about bitbucket improving their hg support. The blog poster,
Sean Farley, was previously working on Kallithea before going to work at
Bitbucket. I met him during Pycon. From my understanding, he's still allowed
to work on Kallithea.

I'm excited about Mercurial's future. There are so many great things coming
out. New ways to handle branching, shallow and narrow clones, an experimental
interface for running hg over a git store...

~~~
smacktoward
_> an experimental interface for running hg over a git store_

It would make me very happy to be able to interact with Git repos through an
interface that didn't make me want to kill myself with a rusty railroad spike.

~~~
jordigh
Well, if you are feeling adventurous,

[https://bitbucket.org/durin42/hgit](https://bitbucket.org/durin42/hgit)

------
pseudonym
I started with and loved Mercurial as a DVCS, and it still has some QoL
commands that Git requires some hoop-jumping to get at, but ultimately the
deciding factor was the inability to permanently delete branches. Since
branched dev work would fairly regularly have generic names or the names of
the developer working on it, it would always end up being forked and merged
instead of branched and merged, which led to a ridiculous number of headaches
in our build system.

We still use mercurial for most of our repositories just because they're dated
and not likely to see more than a handful of commits a year, but most of our
active development work has already converted to git.

~~~
sampo
> inability to permanently delete branches

If your workflow fits better with git-style branches, you should use Mercurial
bookmarks, not Mercurial named branches.

Mercurial even tells you:

    
    
        (branches are permanent and global, did you want a bookmark?)
    

every time you create a named branch.

~~~
loxs
Well, IMHO, nowadays this classifies as bad design. It may have been the
better design, but currently git's nomenclature is the standard and not
complying to it will only hurt mercurial.

~~~
ngoldbaum
Mercurial and git were initially released within a couple of weeks of each
other. To change terminology now would break ten years of backward
compatibility.

~~~
loxs
I understand that, but my point is still valid. Mercurial is not "guilty"
about this, but certainly suffers

------
ptype
I wish Bitbucket would invest some time implementing 2FA. It's 2015.

[https://bitbucket.org/site/master/issue/5811/support-two-
fac...](https://bitbucket.org/site/master/issue/5811/support-two-factor-
authentication-bb-7016)

------
pbreit
It seems to work OK but monthly releases for version control software scares
the heck out of me.

~~~
jordigh
Don't be scared. Mercurial is _very_ conservative about what a new release can
do. There are lots of rules, and they are treated very seriously:

[http://www.mercurial-scm.org/wiki/CompatibilityRules](http://www.mercurial-
scm.org/wiki/CompatibilityRules)

------
imakesnowflakes
Mercurial user for the past 6 or 7 years here. I cling to Mercurial despite
people asking me to move some of my side projects (nothing substantial though)
to git and github.

I refuse to do that out of principle. I think Mercurial should have taken the
place of git as the widely used DVCS. And I try to be THAT change I want to
see.

That being said, It would be great if someone can get the hg-git plugin to
work seamlessly with newer versions of Mercurial on Windows and Linux, so that
I can keep using Mercurial even if a project I am involved in uses git.

~~~
100k
I was really surprised that Git "won" because I thought that Mercurial's
friendlier CLI and being written in Python would give it an advantage. I think
I underestimated how good it makes people feel to understand something
incredibly complicated. I guess immutable history was a turn off for many
people as well.

This fake interview is pretty funny:

"Linus: Git has taken over where Linux left off separating the geeks into
know-nothings and know-it-alls. I didn’t really expect anyone to use it
because it’s so hard to use, but that turns out to be its big appeal. No
technology can ever be too arcane or complicated for the black t-shirt crowd."

[http://typicalprogrammer.com/linus-torvalds-goes-off-on-
linu...](http://typicalprogrammer.com/linus-torvalds-goes-off-on-linux-and-
git/)

~~~
xiaomai
That is a clever fake interview quote, but the whole notion that hg's "easier"
interface should have made it won misses the point. hg's interface is more
familiar (especially since we were mostly all coming from subversion at the
time). Git won because it's workflow is so much better than mercurial's.
Light-weight branches are better than hg branches (I know they have bookmarks
now but I don't recall if they had them back then). The index is a fantastic
idea that makes writing clean commits easy (I think the comparable hg option
at the time was mercurial queues which are much more cumbersome to work with
imo). Rebase is functionality that hg didn't include out of the box. Being
able to edit commits in git is something I greatly appreciate for fixing typos
and stuff.

tl;dr: the interface of mercurial may be more straightforward, but git won
because it allowed people to work better.

~~~
twic
You're right that Mercurial didn't have bookmarks until years after Git had
branches. There were various things you could do to get a similar effect (eg
having a branch with multiple heads), but none quite as good, and it took the
Mercurial team a long time to come around to the idea.

I have to disagree about the index, though. I use Git every day, and i'm still
struck by how pointless the index and the idea of staging is.

Ditto rebase. The routine use of rebase still seems completely wrongheaded to
me. Mercurial's convention of preferring merges is better, and the last few
years' developments around safe evolution of history really show rebase up as
the misconceived hack it is.

Mercurial got 'commit --amend' a long time ago, but even before that, it had
'rollback', which undoes the last commit, leaving the working tree untouched
(that is, with the state it had in the commit), so you can make your fixes and
commit again.

I'd entertain the argument that Git won because it was better if even a
handful of the people who now use Git had learned both Git and Mercurial and
made an informed choice between them. That simply does not appear to be the
case. Git got ahead because Linus invented it, and won because of GitHub.

~~~
DigitalJack
staging is wonderful. I'm sure hg must have something similar.

I can't tell you how many times I've shot myself in the foot accidentally
committing stuff to svn when I just meant a single file.

~~~
reinhardt
I don't use hg much these days but you can just pass the file(s) you want to
commit to 'hg commit'; no need for staging. Even better, hg (or its shell
integration at any rate) has tab completion so it's easy to go though the
modified files and pick those you wanted to commit. I kinda miss this now I'm
working with git mostly.

