
I'm going to slowly move on from Mercurial - jordigh
https://www.mercurial-scm.org/wiki/mpm/transition
======
indygreg2
10+ years is a long time to steward a project. Most projects don't even live
that long!

Transitioning away after 10+ years is a sign of several positive things:

* Creating a successful project that lasts 10+ years

* Having the perseverance, patience, and willpower to guide that project for its lifetime

* Creating a healthy community whom you are able to transition day-to-day responsibility of that project to

Matt has accomplished something that most of us never will. I'm envious of
what he has accomplished and that he is able to walk away from a healthy and
successful project. Truly a remarkable accomplishment.

------
BuckRogers
Matt has done a great job and I wish hg had taken off more than it did, though
it would be disingenuous to suggest it hasn't been successful.

I used hg before moving to git and always preferred the clean, single language
implementation vs the scripts and general hackish nature that git offered as
an alternative. As a result, it was a nice perk for a long time that hg worked
much better than git on Windows.

~~~
masklinn
Also the revsets, while they're relatively recent in the grand scheme of
things (hg 1.6 circa 2010) I so miss these when I have to use (or even read
the man page of) the garbage fire that is `git log` (templates also help)

~~~
roddds
What is it about these revsets that can't be achieved with a "git log --graph
--decorate --all"?

~~~
jordigh
Those would be accomplished with hg templates, not revsets. Revsets are kind
of like gitrevisions(7), but much more powerful.

Docs:

[https://selenic.com/hg/help/revsets](https://selenic.com/hg/help/revsets)

A complete example, which appears to have some popularity in Mozilla:

[http://jordi.inversethought.com/blog/customising-
mercurial-l...](http://jordi.inversethought.com/blog/customising-mercurial-
like-a-pro/)

edit: Sorry, the --decorate part would be with template, the --all is kind of
like a revset, and the --graph part is well, --graph.

~~~
masklinn
> Those would be accomplished with hg templates

Except for the --graph part which would be accomplished with --graph of course

> Revsets are kind of like gitrevisions(7), but much more powerful.

And easier to read and write too.

------
ChuckMcM
This is a gutsy thing to do with a piece of software that has been part of
your life for over a decade. Mad props to mpm.

Up until Blekko I had pretty much been a perforce user (both at NetApp and at
Google) and git was "that weird system you had to use to check in kernel
changes". Blekko used Mercurial and I had no opinion as I had no experience.
But over the years using hg at work and then starting up a github account to
learn git, I saw the writing on the wall. Hg was the betamax of source code
management systems. Clean, elegant, reliable, and not mainstream.

------
andrewla
For context here, and for people like me who don't follow the development of
Mercurial closely enough to realize, mpm is not just some random contributor
to Mercurial, but is in fact Matt Mackall, the original author of Mercurial.

~~~
jordigh
Lest we forget, Mercurial was offered as the other solution to the Bitkeeper
problem, as mpm was a kernel hacker at the time. It got a usable UI at version
0.1, two weeks after the git announcement. Some git users relied on cogito for
another year or so, as simple things like `git-commit` still had to be
manually handcrafted out of `git-commit-tree`.

I wasn't there to witness this, but I repeat it because it's actually kind of
hard to dig up this history. I don't know of a single place that neatly
chronicles the whole transition from bitkeeper -> git/mercurial.

~~~
JoshTriplett
> Lest we forget, Mercurial was offered as the other solution to the Bitkeeper
> problem, as mpm was a kernel hacker at the time. It got a usable UI at
> version 0.1, two weeks after the git announcement.

I remember using Mercurial very early on in its lifetime, during my first
internship at IBM, because Xen used it.

Mercurial also ran on Windows far, far earlier than Git did. A few projects
(notably Mozilla) selected Mercurial for that reason, because they had
developers on Windows.

Unfortunately, Mercurial took longer to develop some of its infrastructure,
such as a repository structure optimized for performance, fast branches
without making a separate working directory for each, and history editing
capabilities. Today, as far as I know, Mercurial does have all of those things
(some through plugins).

> Some git users relied on cogito for another year or so, as simple things
> like `git-commit` still had to be manually handcrafted out of `git-commit-
> tree`.

Many people (myself included) also used cogito as a crutch for a while longer,
until really internalizing the value of the git index, because cogito
defaulted to bypassing the index. I originally saw the index as an obstacle to
the commit model I'd gotten used to from subversion. Today, I find it a
critical part of git's culture of making small commits with one logical change
each.

~~~
zeveb
> Mercurial also ran on Windows far, far earlier than Git did. A few projects
> (notably Mozilla) selected Mercurial for that reason, because they had
> developers on Windows.

Ouch, yet another way in which running on Windows can lead to poor technical
decisions.

In my own case, I really preferred hg's command congruence to SVN; git's
deceptive similarity took a long time to get over.

> I originally saw the index as an obstacle to the commit model I'd gotten
> used to from subversion. Today, I find it a critical part of git's culture
> of making small commits with one logical change each.

Same here, on both counts. I'd never go back, now, but it did take time to
understand the benefits.

~~~
jcranmer
It's worth pointing out that part of the reason that Mozilla selected
Mercurial over Git was that the Mercurial developers were more willing to help
fix issues that Mozilla had identified than Git was, with Windows support
being the most important point.

In a way, actually, that still seems to be the case. The Mercurial community
seems to be working hard on making enormous monolithic repositories much more
performant and realiable, whereas a lot of Git community seems to prefer to
merely respond "YOU'RE USING IT WRONG" to these issues (although I suspect the
developers themselves are also working on some of the issues; it's just that I
see the community at large as much more visible).

So there's definitely a sense to me that Mercurial is the better VCS because
it will quietly support whatever development model you want to use, whereas
Git tries to force you to use the One True Model™--and I'm firmly in the camp
that development tools should support developers' habits, not force them.

~~~
glandium
_> So there's definitely a sense to me that Mercurial is the better VCS
because it will quietly support whatever development model you want to use,
whereas Git tries to force you to use the One True Model™_

Considering the number of tools based on the Git data model to do completely
unrelated things (I'm thinking about e.g. bup or git-annex). I wouldn't say
that's Git imposes you a One True Model. Also, Git doesn't restrict you to an
arbitrary number of parents on a commit ;).

BTW,

 _> The Mercurial community seems to be working hard on making enormous
monolithic repositories much more performant and realiable_

The irony is that to do so, Mercurial had to bend its data model, adding
(backwards incompatible) support for per-directory manifests (which sound a
lot like trees in Git, except the part where manifests have history attached
to them, where Git only has history attached to commits).

------
krupan
I'm really surprised by the "git won" mentality that manifests in any
discussion of mercurial as of late. It makes no sense. We don't decare
"winners" with other tools we use. Do we?

Why are we all playing with new programming languages when C won? Or maybe C++
won? Or Java? Did emacs or vim win? Speaking of text, did ASCII win? Which
code review tool won? How about continuous integration tools? or build tools?
I mean, make won, right?

None of us just pick the most widely used tool or programming language and
say, "there can only be one" and then stop trying new things. Why are we doing
this with version control?

~~~
slapresta
Code collaboration tools have a strong network effect due to them being
ultimately social tools, and we expect categories affected by the network
effect to have winner/losers mechanics. Of course, they don't actually have
to, but it's a common expectation and a common outcome.

For equivalents to "code collaboration tools", instead of "programming
languages", "text editors" and "build tools", try "social networks" (Facebook
won, MySpace lost), "network protocols" (HTTP won, FTP and Gopher lost) or
"spoken languages" (English won)

~~~
pjmlp
> English won

English did not won.

It might be widely spoken in the 21st century, but so were Greek, Egyptian,
Latin, French, Portuguese and Spanish once upon a time.

I might be writing this in English now, but saying it won implies no change in
common language will ever happen again.

Given the history of mankind and some of the countries I had the pleasure to
visit on my life so far, I doubt it.

Specially since most of the people I know, do happen to speak three foreign
languages on average.

~~~
amake
> English did not won.

Apparently not.

------
dochtman
I was a Mercurial crew member for a few years (2008 to I don't know) and was
very happy to be able to learn from Matt in his role as BDFL. His principled
stance against layering violations and his policy to require really small
commits still influence my coding every day. I hope he finds something new to
give him satisfaction/joy!

~~~
tonfa
+1, working with Matt was also extremely formative, I learned a lot of best
practices during those years.

------
pjmlp
I loved Mercurial, but just like with Wirth languages, I seem be on the wrong
side of the mainstream flow.

Thanks for Mercurial!

------
yeukhon
I did a project on integrating Mercurial with Mongo before, and I have to say
being a Python developer I didn't have too much difficulty in figuring the
right API, although the documentation is not so great. The code itself uses a
lot of abbreviations which you have to really be patient to get familiar. The
Mercurial model [1] is a pleasant read for a couple train ride (read it a few
times I encourage). Others have done amazing things with hg too, like making
hg available in Javascript (now an abandon project).

Mercurial is actually very easy to use. However, it didn't have the exact
lightweight concept of git branch until they implemented bookmark a few years
ago. I don't remember the limitation of bookmarks now it has been a few years
since I used Mercurial...

I too thank Matt and core developers working on Mercurial. One thing I feel
Matt and developers need to address is hosting hg on PyPI infrastructure
instead of redirecting to their own server. From time to time the server
wouldn't deliver anything and it was frustrating to see our builds fail (of
course some say you should have cached the build and not hitting Mercurial
server every day).

[1]: [https://www.mercurial-
scm.org/wiki/Presentations?action=Atta...](https://www.mercurial-
scm.org/wiki/Presentations?action=AttachFile&do=get&target=ols-mercurial-
paper.pdf)

~~~
durin42
We've been uploading to PyPI as part of our release process for quite some
time, and our own server is hosted on public infra now instead of on a
privately managed machine. :)

------
AndyMcConachie
Thanks for all your contributions over these years.

~~~
isxek
Thanks for starting Mercurial.

------
nailer
hg could be 20% better than git. For the sake of the arugment, let's say it
is.

git's network effects mean hg needs to be 1000% better than git to replace it
(much like git replaced svn, svn replaced cvs, and cvs replaced rcs).

~~~
umanwizard
There are tons of companies using mercurial including some of the biggest
ones. It's not really accurate to imply that Git won and Mercurial is dead.

~~~
amadvance
I consider the CPython switch from Mercurial to git the final declaration of
victory.

I still have to understand how CPython could miss the symbolic meaning of this
decision.

~~~
no__one
More Guido and a couple of vocal people than CPython. I truly hope the switch
wasn't the reason for Mackall to quit.

~~~
durin42
Nope. mpm has been wanting to move on for a while, it's only recently that
he's published plans more publicly.

------
bedros
I talked with an engineer from a fortune 500 tech company and they chose git
over other vcs because they could have permission control; they have sensitive
sub project who needs only a small set of engineers with permission to access
it, but that subproject/module is part of a bigger project that everyone has
access to.

I personally prefer HG over git and use it for my own personal projects,
hosted on my own redmine server. I tried bitbucket, and github; the latter
have s superior interface to bitbucket. which I believe why people picked
github over bitbucket

------
harry8
You find yourself in a realm where hackers don't branch and use svn with no
experience of distributed source control.

hg is so much your friend here. They will actually probably get over the
switch hump and use it. git that hump is much bigger and more arduous. Git is
great, I like it. When you want to drag the team with you who aren't already
sold, just go straight to hg every time. You're hacker, you can use either
effectively and both are excellent tools.

------
acveilleux
I believe that Mercurial's greatest flaw is that it is too damn easy to use.
Since you don't have to wrap your head around it so damn much to use it, it
seems weak, like if it was only slightly better than subversion.

The truth is different and Mercurial is roughly as capable as git but it's
easy to miss Mercurial's power where as Git rubs your face in it (less so
these days but early on, it was a brain f __* to my CVS trained brain.)

------
oscarcardoso
If you ever see this, Thank you Matt. It helped me a lot to get away from
subversion by working with hg at the same time.

------
stevelosh
I've only contributed a few patches to Mercurial but meeting Matt and learning
from him (mostly on the HG mailing lists) has taught me a lot. He's influenced
how I think about and work with code at a really basic level. I wish him the
best in whatever he decides to do.

------
dhimes
Thank you, Matt. hg is still my choice in source control. It's the only one I
really use.

------
22klinda
I've used Mercurial on Bitbucket in the past and loved it. Very thank you for
your hard workd, Matt. Too bad that git is on everywhere now.

------
anarazel
I think hg was/is important, to provide competition to git.

But I don't really understand all the people arguing that hg is so much easier
to use, and so much cleaner. Sure, in the first few years that was true, and
there's architecturally better choices (not a mess of scripts, embeddable as
library). But from a day to day usage, hg seems worse to me. And that includes
the documentation, something that really surprised me after I had to restart
using hg a year or so back.

The whole thing how hard it is to actually get rid of branches (no, I do not
want to merge that branch. Yes, I don't want any central record anymore. No, I
don't want to ssh into the remote box. Uh....), really bugged me. So does the
need, slowly abating, to activate a lot of random plugins to get functionality
that git had for years (pagers, incremental add, staging area, ...).

But I very well, and I actually mean that, might just be mind warped by having
used git so long and so continually that I just don't see the problems anymore
and it just seems easier. I do remember some initial difficulties
understanding it, but that was in the quite early days...

------
antonyme
Mercurial has to be one of the best examples of incredibly high quality
Software Engineering out there. It is very well-designed, reliable, fast, easy
to use, well-documented and has a great community behind it. Matt deserves
huge kudos for his enormous effort and commitment over the years. And like a
true gentleman, he is leaving in style to ensure the transition is smooth.

