

Ask HN: Google/FB engineers, Do you like Mercurial? - gitdude

All the Google and Facebook engineers who are currently using Mercurial, I want to hear from them how they feel about Mercurial over Git. If they leave GooG or FB, will they still use Mercurial?
======
andreastt
The problem with this question is that there are so many _different ways_ to
use Mercurial. hg's core is fairly minimal and everyone I know who uses it
rely heavily on core- and third party extensions to get any productive work
done.

Mercurial does a good job at facilitating everyone's favourite, yet obscure,
workflow. There are people who prefer using things like mq (patchset queues),
which until recently also was Mozilla's recommended workflow. Queues are a
novel way to organise your work in progress, but is quite different from what
people are used to coming from svn or git.

More recently bookmarks were added (also as an extension you have to opt-in
to), which are reminiscent of git branches. They make it possible to have a
HEAD-based workflow where you rebase frequently, much like you would with git,
only that the defaults of `hg log` and various other commands don't interop
very well, which means you have to memorise a lot of flags and arguments.

There are also many strange defaults in hg that you simply have to get used
to, for example that `hg push` by default pushes everything. I have a hook in
place on the remote end which prevents me from doing that.

By far the most frustrating experience with hg is that you cannot expect the
default installation to come with sensible defaults. The argument is that
keeping "advanced" functionality out of core prevents new users from
accidentally using it.

An unintended consequence is that it sometimes makes it difficult for other
people to help when you're stuck because more often than not their environment
won't match yours.

One frequently lauded aspect of hg is that the user interface is easier to
understand. Whilst I appreciate difference in taste, my experience is the
opposite. If you follow the HEAD-based bookmark-style workflow, I find many
cognitive dissonances in how the bookmark feature interacts with other
commands.

At Mozilla we use hg for the canonical repositories and we have many Mozilla
related extensions, but whereas I use hg every day now and it's a fine
experience as long as I stay within the marked lines, I would return to git in
a heartbeat if I had the chance.

~~~
krupan
"The problem with this question is that there are so many _different ways_ to
use Mercurial. hg's core is fairly minimal and everyone I know who uses it
rely heavily on core- and third party extensions to get any productive work
done. Mercurial does a good job at facilitating everyone's favourite, yet
obscure, workflow. There are people who prefer using things like mq (patchset
queues), which until recently also was Mozilla's recommended workflow. Queues
are a novel way to organise your work in progress, but is quite different from
what people are used to coming from svn or git."

Up to this point your comment was true, objective, and very helpful (though I
would remove the word "obscure"). Then it starts to sound like maybe you
learned git first and got used to it's defaults and now mercurial tastes a
little funny to you. I'm guessing this because I got good with mercurial first
and then when I tried git it left a funny taste in my mouth. I thought, what
is this "fast-forward merge" that doesn't actually merge anything? Why do
people talk about deleting a branch when it doesn't actually delete the branch
of commits in the DAG of commits, just a pointer? Why does pull do a pull
(fetch) _and_ merge (mercurial's pull just pulls, or fetches, I guess)? Stuff
like that.

~~~
jordigh
There's definitely a lot of baby duck syndrome on both sides of this git-vs-hg
thing:

[https://en.wikipedia.org/wiki/Imprinting_%28psychology%29#Ba...](https://en.wikipedia.org/wiki/Imprinting_%28psychology%29#Baby_duck_syndrome)

Habituation is the best user interface.

------
mrweasel
Why only Google and Facebook engineers?

I use both Mercurial and Git, and honestly, they aren't that different. Unless
you're doing something very specific I don't see why you would choose one over
the other.

~~~
thanksgiving
I've never used mercurial outside of TortoiseHg. In fact, the only time I've
used mercurial is when I was attempting to build Firefox from source before I
realized that they do a git mirror thing so you don't have to touch mercurial
at all.

I don't know much about mercurial. I use git because somebody said it is
easier to rewrite history in git.

~~~
dcuthbertson
I don't believe the ability to rewrite history is a good idea. One of the
reasons I like Fossil-SCM is that you can't rewrite history.

~~~
voidr
> Subversion uses a centralized revision control model. Ben Collins-Sussman,
> one of the designers of Subversion, believes a centralised model would help
> prevent "insecure programmers" from hiding their work from other team
> members.

source:
[http://en.wikipedia.org/wiki/Apache_Subversion#Limitations_a...](http://en.wikipedia.org/wiki/Apache_Subversion#Limitations_and_problems)

Sounds like you should be using Subversion then.

Do you understand how history rewriting works in git? do you understand why
it's there? do you understand why people use it?

Personal beliefs don't advance computing, hard facts do.

~~~
durin42
Note that Ben (a personal friend) has been an enthusiastic user of Mercurial
for several (4? 5?) years, and is pretty happy with it. He was even using
hgsubversion for a while I think.

Note that there's a lot of social problems around DVCS, and the thing Ben
worried about is still a _real problem_. I get potential contributors showing
up with _months_ of work, and it's an enormous pain in the ass (both for them
to rewrite and for me to beg them to work with me) when they did something
architecturally unacceptable early in the process that a simple 2 minute
review could have caught.

~~~
krupan
But would the insecure people have done that work at all if they knew they
would be forced to commit it publicly? Maybe so, but would it all be one huge
commit to svn instead of maybe a string of more concise commits to git or
mercurial?

I just envision someone insecure (like I feel at times) saying, well, I'll
just clone this and play around on my own machine. Then after making some
commits and building up courage, saying, OK, I'll try and go public with this.
With centralized VCS that seems _less_ likely to me. The insecure programmer
just won't even try. I don't know, it's probably different for different
people.

------
gcb0
heavy mercurial user. all my open source projects are on it. first at Google
code (rip) and now on bitbucket.

though i have to use git at work daily. github to add insult...

my finger memory is now on git. and that's where git "wins". the chance that
you will be forced to use it and learn the awful laundry list of steps to
properly use it (hint, if you ever type "pull" you are doing it wrong) you get
your finger memory and then curse when you have to use the simple and more
intuitive solutions. damn dumb fingers.

~~~
lifebeyondfife
> hint, if you ever type "pull" you are doing it wrong

Genuine question: what's wrong with executing 'git pull' on a branch you
haven't changed locally?

~~~
ehotinger
Nothing unless you're rebasing upstream, but I think the point he was trying
to make was that you should always run `git fetch` and then `merge` from there
(again, there are some situations where the pull is fine IMHO).

~~~
c0wb0yc0d3r
_git pull_ just runs _git fetch_ then _git merge_.

At least that is what the docs say: [http://git-scm.com/docs/git-
pull](http://git-scm.com/docs/git-pull)

What am I missing?

~~~
gcb0
but it tries to be smart about how to merge. and usually it's not what you
want. i consider it the clippy of linus.

if you run merge/rebase/etc on its own, it will tell and ask you about
anything out of the ordinary and then there's no surprise.

again, it's all about avoiding errors on the rare cases because you developed
dangerous finger memory.

------
FraaJad
the question about mercurial by "gitdude" is very umm.. leading.

~~~
lifebeyondfife
You can be a fanboy about something and still want to understand why people
prefer the alternative.

------
heyts
Honest question: could someone summarize why would one use mercurial vs git?
Both seems really close in features. What would be a use case where one would
outshine the other?

~~~
jordigh
I promise I'll turn this FAQ you just posed into a wiki page... in the
meantime,

[https://news.ycombinator.com/item?id=9467096](https://news.ycombinator.com/item?id=9467096)

------
jordigh
Google is working on integrating Mercurial into their workflows, but hasn't
quite achieved this goal yet. They are growing their hg team with hopes of
replicating what Facebook has done, but they aren't there yet. Check out their
contributions:

[http://selenic.com/hg/log?rev=google.com&revcount=80](http://selenic.com/hg/log?rev=google.com&revcount=80)

Facebook is almost entirely hg by this point, though.

------
raldi
Mercurial is almost unknown at Google.

------
marvel_boy
I did some work on Hg and I liked, but now EVERYBODY is using Git. Very
similar systems by the way. I work on iOs apps.

