
Mercurial vs Git: Why Mercurial? - LeafStorm
http://blogs.atlassian.com/2012/02/mercurial-vs-git-why-mercurial/
======
acdha
The part which struck me: "For the times when you do need to rewrite history
in Mercurial, you can turn to extensions like collapse, histedit and MQ.
Keeping this functionality out of core prevents new users from accidentally
using it until they’re ready."

What this means in practice: when you need to rebase in Git, you simply do so.
When you need to rebase in Mercurial, you have to enable a bunch of extensions
which aren't well polished or documented because they're not part of the
standard feature set and many people have been discouraged from using them.
That second situation is far more likely to cause data loss, which is a pity
because rewriting local history is a valid operation which often produces
cleaner commits and avoids merge failures.

I started using Mercurial earlier than Git but have been using both for years.
Mercurial remains the only one where I have experienced data-loss (histedit)
and the one where I had to switch to a less natural workflow to deal with
limitations of the tool (e.g. patch queues are such a kludge-fest it's obvious
that nobody really believes you should use this feature).

~~~
kisielk
To be fair, the MQ and rebase extensions are shipped with mercurial, just not
enabled by default. They share the same bug tracker as the main project and in
my experience are just as well documented and tested as other bits of
Mercurial.

It's also been my experience that non-expert users don't understand the
repository DAG model well enough to perform history rewriting reliably and
without error, which I think is one reason these features are disabled by
default.

Finally, as of Mercurial 2.1 they now have the concept of "phases" of commits
which make local non-shared commits mutable whereas commits which have already
been shared are immutable. This new feature is a first step to safer history
editing operations becoming more mainstream mercurial commands.

~~~
guard-of-terra
Why should I have to assemble my DVCS from parts before I would be able to use
it? If I wanted Lego I would have got one.

Shelf isn't shipped with mercurial and it's really really painful without it:
you make some changes to some wrong branch and now you need either shelf or
major pain with rebase.

If non-expert users don't understand enough to do rebase, they're screwed:
they better go cry in a corner since you can't solve any non-trivial scenarios
without rebase and you're going to run into those all the time.

Not that I like git, but still. And since Eclipse plugin for SVN merges much
better than both git and hg, I often wonder why do we bother at all :(

~~~
sreque
Your comments highly suggest that you are not by any means a knowledgable
mercurial user. You don't have to "assemble" mercurial from parts to do
history rewriting. Enabling the relevant extensions amounts to adding a single
line to a config file. I usually copy the same config file around when
installing mercurial anew so that I can cut out even that step.

Shelf isn't that necessary because of mq, which is bundled by default. It is
very feasible to use mq as a simple shelf substitute, much easier than using
it for its more complex usage scenarios. Also, for your use case, it's pretty
easy to hg diff your change to a file, switch branches, and then use the GNU
patch command to apply your changes on top again, so you don't even need shelf
or mq to do that if you haven't checked anything in.

~~~
ramses0
I can't count the number of times I did:

    
    
        cd $PROJECT
        svn diff > ~/working-on-foo.patch
        svn revert *
    
        patch < ~/working-on-bar.patch
    
        30 GOTO 10.
    
    

Ugh. Thinking about going back to that workflow makes me physically ill.

Git (as Linus says) is a STUPID content tracker. 99.9% of the time when I'm
working on source code, git allowing me to do stable, local "bookmarks", keep
multiple local branches (and local history) active simultaneously, and keep
all my content tracked... Git has its flaws and warts but don't seriously
suggest that "svn diff > ~/working-on-foo.patch" is a valid workflow. That's
bringing a knife to a gunfight.

I suggest that if you can understand a linked list, you can understand git.
And if you're a programmer that can't understand a linked list... well...
print out your "cheat sheet", here's a copy of Tortoise, and commit your code
to a branch before it gets approved for main-line.

~~~
sreque
I only suggested the diff/patch workflow for the simple case where you
realized after making edits that you were in the wrong branch. It might even
be possible to just update to the correct branch and have mercurial
automatically try to remerge your changes, though I haven't tried to know for
certain. I think you're taking my suggestion way out of context, though I
could be misunderstanding you.

Mercurial has remote-trackable bookmarks now (something I felt they needed for
a long time). I agree Mercurial's branch tracking in general isn't nearly as
good as git's, local branches being the biggest example. There is a local
branch extension for mercurial
(<http://mercurial.selenic.com/wiki/LocalbranchExtension>), but having used it
a long time ago I'm not sure I'm the biggest fan.

However, I firmly believe that mercurial is in the same league as git and both
are more than good enough to get the job done, and each have their relative
strengths and weaknesses. I also believe that the outspoken part of the git
community tends to be overzealous and blind to git's faults and Mercurial's
strengths.

------
postfuturist
Why would their product marketing manager be bashing Git with accusations like
Windows support is a "completely separate project" when it's the first
download link on git-scm.com?

This is a very thoughtless article full of issues of personal taste and FUD
towards Git. I was starting to really like Atlassian since they added free
private Git repos on bitbucket.org. We've been considering using JIRA and
other paid services from them where I work, but this gives me serious pause.

~~~
frio
Not that I'm biased here (I use git and am more than happy on it), but git on
Windows is an abomination as compared to Mercurial. Other than the sometimes
complex commandline statements, it's one of git's bigger problems.

~~~
jandy
An "abomination", really?

I use Git regularly--and happily--on Windows with very few issues. It is
considerably slower than its Mac/Linux builds, but aside from that the
experience has been positive.

What exactly do you consider to be Git's failings on Windows? And how is
Mercurial superior in those respects?

~~~
statictype
I haven't used git on Windows for some time now so maybe things have changed,
but at that time, it was pretty obvious that Mercurial was a polished first-
class citizen of the Windows platform while git was an incomplete port (and in
git's defense, I don't believe "make it work on Windows" was ever a design
consideration when it was written).

I presume things have changed since then but it wasn't always the case.

~~~
bwarp
I have found the same things, even recently.

Git for windows basically brings half of MinGW with it including a shell and
pisses up your windows cmd settings terribly. There is no platform abstraction
layer in Git, so you're stuck with dragging GNU with you (it's not even POSIX
compliant).

Mercurial is far more respectiful as it uses Python as the platform
abstraction layer, uses windows semantics quite happily and considered Windows
very early on.

Mercurial is just more polished on Windows.

Also the IDE integration and tooling on Windows is an order of magnitude
better. It just works with no fannying around.

Add to that it's considerably less cryptic than Git and it's won.

~~~
bwarp
Downvoted by a git fanboy...

------
NelsonMinar
GitHub is the first and last reason to prefer Git to anything else. That
community is so vital right now, it cements Git as the essential VCS. I could
believe Mercurial is better in some ways than Git and I could even believe
Atlassian's BitBucket service is in some theoretical sense better than GitHub.
But most code is on GitHub, so git wins.

~~~
StavrosK
There are 6 responses your comment and not one has mentioned that both hg and
bzr have full interoperability with git. I use github extensively with both
bzr and hg, and haven't used git in a while. Your personal choice of SCM is
entirely irrelevant to which web service you use.

~~~
fryguy
As a lover of bazaar, how did you manage to do that? I always feel so dirty
when I have to use git because everyone uses github.

~~~
StavrosK
Just use bzr-git, it works perfectly.

------
badboy
It is a bad thing to have just _one_ command to move files instead of 3? Nah,
I don't get it.

That git has different commands than svn is because it _is_ different. Why
should it adopt any of the commands if it does different things?

When I started with git, I _never_ _ever_ destroyed any of the history.
Because it's not easy to do so.

I looking forward to read the follow-up article where he wants to point out
some advantages of git.

------
aninteger
Regarding the "A Sane Command Line Interface" topic. Linus mentioned in his
talk at Google about Git that he often chose the opposite approach to do
things rather than follow the Subversion approach. This might be why the
commands are not named the same as Subversion commands.

git add/rm handles making changes to the index and there is no similar concept
in mercurial or subversion.

~~~
Argorak
I think this is not only about similarity. For example, branching works with
`git branch foo`, but it doesn't immediately switch to that branch. If you
want to do this, `git checkout -b foo` is the way to go. While this might make
some sense if you understand the details behind git, it is horrible from a
user interface perspective. I know a lot of people that didn't know about
checkout -b because they never thought about looking there.

Also, some features are half-implemented, for example `git add -p` which does
not trigger on file-additions (and sometimes is broke out of the box on some
distros).

I like git, but the interface: not so much. Too many rough edges.

The blog post does not illustrate this, though :/.

Update: and for the downvotes, would you care to explain why?

~~~
weaksauce
I'm not downvoting you but the git branch command is orthogonal to checking
out a branch. The branch command adds, removes and lists branches. The
checkout command switches between them. There is a convenience command that
does a checkout and create. The main thrust of the checkout command is to
change branches so if a branch does not exist they give you a convenience
method to do so.

edit: git add -p(atch) is supposed to create patches of existing files
assuming that that is the most common use case. Use --interactive if you want
to add new files and still do interactive patching.

~~~
Argorak
I am aware why the distinction exists - from the perspective of "git(1)
manipulates the git file system", it make sense (as I wrote). But most people
I know tend to use "branch" for all their branching work (as the name implies)
and never bother about the finer details. But the fact that this sore point
exists and is real makes the git UI problematic. I don't bother, because I
know the details, but if I have to explain it to every new guy in the office,
there is something wrong.

About git add -p: yes, I am aware of -i, but it doesn't give you the easy
"give me all changes to the file system and let me sign them off"-interaction
that git add -p has. They are two completely different interaction modes.

~~~
weaksauce
git add -i

5<enter>

*<enter>(all changed files) or 1-5<enter>(files 1-5 in the list) or 1,5,3<enter>(files 1, 5 and 3) etc...

then <enter> gets you to the staging that you are used to. this will get you
into the quick patch mode that -p does.

-p is just a short circuit of this.

------
jcoder
"Backwards Compatibility

The maintainer (and original author) of Mercurial, Matt Mackall, is a strong
proponent of backwards compatibility, which is important when you’re choosing
a version control system that you plan to rely on for a long time."

Well, that's air-tight. You sold me.

~~~
outworlder
And since when GIT ever broke backwards compatibility?

 _almost never_. Details below:

[http://stackoverflow.com/questions/1314668/git-repository-
ba...](http://stackoverflow.com/questions/1314668/git-repository-backwards-
compatibility)

~~~
aninteger
I'm pretty sure jcoder was being sarcastic :).

~~~
jcoder
Yeah, just drawing attention to the "rigorous discussion" (hand waving).

------
falcolas
I find the "Easy to Extend" argument very unconvincing.

The example shell script is not at all integrated with hg (no more so than any
other Unix command), and these are not Windows portable, as the article
indicates is so very important. Git appears to have an edge here, since you
can integrate shell scripts directly into the git interface.

Git allows aliasing just as easily as hg.

------
benatkin
I like what's on the git part of the table better, and it isn't just
familiarity with git but familiarity with unix. I'm glad that since I use git
and git-svn, I don't have to type remove and move instead of rm and mv.

~~~
LeafStorm
One thing the article misses is that hg also has a bunch of built-in aliases
for a lot of these commands, including:

* mv for move

* rm for remove

* co for clone (which SVN uses as an abbreviation for svn checkout)

* ci for commit

As well as the fact that you can abbreviate _any_ command that hg doesn't have
specific aliases defined for by typing any unambiguous prefix. Git, on the
other hand, has _no_ aliases by default, and no prefix aliases.

~~~
buff-a
Gosh, I know. That's awful. Its much better that hg allows people to type hg
mv, rather than _forcing_ lazy people to modify the .bashrc file so that they
can type "ga" instead of "git add".

I mean, I know "hg mv" is actually _longer_ than "ga", but by golly, expecting
unix shell users to know about the alias system _built into the operating
system_ is just the kind of elitism we can expect from linus.

~~~
benatkin
I hate to burst your bubble, but git has alias support.
<http://githowto.com/aliases>

------
LeafStorm
The fact that the average HN'er seems to be completely unwilling to even
_consider_ using a tool different than git is rather depressing. While I
understand that git does have some impressive features that Mercurial does
not, most of them are somewhat esoteric, and I certainly doubt that they are
enough of a motivation to justify this viewpoint that git has already won and
that Mercurial is a pile of trash.

"The more I use git, the more I realize that everyone enamored with it has a
severe case of Stockholm syndrome." -- Matt Might [1]

[1] <https://twitter.com/#!/mattmight/status/161495662033248256>

------
luser001
I did 'git log' on a repo with 60K commits and about 3k files. I finished in a
second or so.

I imported that git repo into Mercurial and did 'hg log'. It took 13 sec.

This was about 3 years ago. I haven't looked at Mercurial again. Maybe things
have changed now?

------
tednaleid
Almost all git vs mercurial differences for most users are
cosmetic/usability/culture related. With a few extensions turned on, you can
use either interchangably. The biggest exception to this is if you use named
branches (a fairly common thing in git, slightly less so in mercurial).
Mercurial hard codes a branch name in the metadata of a commit, git doesn't do
that. I prefer git's method as it means that a commit can move around on
branches (or really that branches can point to different commits) without
messing with the commits themselves.

~~~
elehack
Branching is one of the big differences. I find Mercurial's named branches
mostly useless; fortunately, with some care, bookmarks can be used to simulate
Git-style branches.

I think, early on, the Mercurial community favored cloning as the means of
creating feature branches, while Git used named branches to do so. But in many
cases you want to be able to switch lines of development in a single
repository (especially when using a workspace-based IDE like Eclipse), so the
Git model becomes a win.

------
codesuela
>Many programmers prefer to use a graphical interface to their version control
system instead of working through a command line.

to be honest git is my first true VCS (because I was used to working on my own
and my VCS was Wuala sync that synced every changed document to the cloud +
daily backups to another HDD). I have used the built in revision control
system in Visual Studio but not extensively. When I started out with git I was
looking for a GUI client because I assumed that it would be easier to use but
now I much prefer the cli version of git and I assume this is true for most
Linux (and possibly Mac users idk). I would even go as far as to assume that
this is true for most HN readers. Anyone care to comment?

Also git (even direct publishing to github) is built into PyCharm/RubyMine and
there is also TortoiseGit for Windows (not sure about other OSs)

edit: I just realized this might be slightly OT but I still hope this wont be
downvoted into oblivion as I'd love to hear some opinions

~~~
wonderzombie
For my part, I started using git at the command line because most of the Linux
GUIs were pretty weak. They may have gotten better since I looked (1 yr?) but
at this point I'm comfortable with the command line interface.

Also, I jump between Linux at work and OS X at home, and the git workflow is
the same on either if I am using the command line.

The Mac GitHub app seems really nice, though.

------
wowzer
Having used both git and hg in my own projects, I have strong feelings towards
both, although in the end they're like siblings who got the same lessons from
their parents and just choose to go to different colleges.

With that said, I'm not sure this post really pushes one to use hg. The
comments about being close to svn are pretty lame. While I get the point;
subtle differences really won't matter after the first week. And getting over
the mental difference that comes with distributed version control is a lot
more to take in than a couple letter changes in commands.

The two things I most like about git are how -- by default -- you can choose
line-by-line what gets commited. Where as the default in hg is to commit all
changes. This actually changes how I find myself coding and my comfort with
the repo. I know you can do something similar in hg, but it's a bit of a
nuisance.

The other standout is how simple branching is in git.

------
sdfjkl
I used to worry about Git vs. Mercurial too. Neither made me really happy.
Then I found Fossil[1]. Now I am coding instead of worrying about version
control.

[1] <http://fossil-scm.org>

~~~
wladimir
I eventually settled on git, for no particular reason but to choose one. They
are equivalent for all practical purposes, but require learning different
commands to do the same thing. It was taking too much mental bandwidth for me
to context-switch between them.

It's great to see some diversity though.

Edit: There are also plenty of scripts to convert between repositories of one
format to another, and communicate between them, another reason to use the one
you're comfortable with...

------
jcapote
The need to be a technology contrarian, that's why.

------
cageface
Or, let's be honest, because Github already nailed Git so we had to base
bitbucket on something else.

