
Mercurial vs Git; it’s all in the branches - JayInt
http://felipec.wordpress.com/2011/01/16/mercurial-vs-git-its-all-in-the-branches/
======
eslaught
I find it strange that he calls msysGit a good solution on Windows.

My personal Windows machine has Cygwin, MSYS (for MinGW), and MSVC's own
command line (based on cmd.exe), so that I can use each of those three
compilers for compatibility testing my projects. With msysGit my experience
has not been good at all; patching git into each of the evironments always
seems to require some manual work on my part, despite msysGit's claim that it
can put just the git binaries on PATH.

So quite frankly, I do not think the current Windows situation for git is
adequate, as it has (in my experience) integrated poorly with various command
line environments.

~~~
andrewflnr
That's strange. When I installed it a couple summers ago on Vista, it Just
Worked. I didn't have Cygwin. Maybe a conflict?

------
ceol
_> My recommendation to other people facing similar decisions is to choose the
project that has a brighter future, chances are the “disadvantages” you see in
the present would be resolved soon enough._

That's not what I would recommend at all. There's no guarantee a project will
resolve those issues or that new ones will crop up. Google was correct in
choosing hg because it was the best choice _at the time_ (back in 2008).

It looks like his only positive point are the branches, and then goes on to
say, "The conclusion shouldn’t be that surprising; Git wins." I'd imagine hg
being supported in Windows without requiring a third party install is a big
plus.

I think the first comment puts it nicely: <http://gitvsmercurial.com/>

\----------- edit -----------

It looks like the author had a discussion in the comments:

 _> My objective is to show why Git is superior. So if you care about your own
performance, and the one of your project, the choice is obvious. One allows
you to do many things, the other one doesn’t._

However, this contradicts his previous statement that the differences between
the two are subtle and only proves his bias is heavily influencing his
conclusion.

~~~
Xylakant
I rather dislike how the author dismisses the fact that other people have
other use-cases.

The author chooses one use-case of his liking and demonstrates how (in his
opinion) git handles that use case far superior than hg. I remain unconvinced
that git's handling is actually better and while that may be a common case for
him, I have yet to meet that use case.

I know of at least one company that still uses cvs as VCS of their choice
because it perfectly fits their use case, does exactly what's needed and does
not introduce any artificial complexity. Probably pretty much any modern VCS
rips CVS apart in terms of features and storage model, but I can understand
their reasons. By the authors reasoning they should switch to git because it's
clearly and demonstrable superior in all respects.

~~~
felipec
I did not dismiss any use-case. As I said; they are mostly the same. So, if
you don't need complex use of branches, you would be fine with either git or
mercurial, obviously.

But that's a chicken and egg situation; you don't know what you are missing
until after you try out. Oh, I don't "need" more memory, I don't "need" an
SSD, I don't need a 1TB drive. But once you have them, you suddenly realize
you can't live without them. And that's usually what happens when people
realize how they can utilize git branches effectively.

You are free to disagree, but at worst, they are exactly the same, and at
best, git branches are superior (and so far nobody has managed to demonstrate
otherwise in the 160 comments in my blog). So, why would you pick anything
else than git?

~~~
Xylakant
This is a false assumption and a flawed comparison. An SSD has the same
external interface as a spindle disk. It does have does have different
internal properties though that make it superior in almost all use cases
though.

> You are free to disagree, but at worst, they are exactly the same, and at
> best, git branches are superior (and so far nobody has managed to
> demonstrate otherwise in the 160 comments in my blog). So, why would you
> pick anything else than git?

I actually have to admit that after reading the whole comment thread in your
blog, I'm actually convinced that the HG folks won the argument. Since you're
a git developer it's expected that your takeaway is a different one. It's
probably not that you're biased, but you know the way git does things soo far
better than anything else that this is the way you think and live and anything
else is inferior.

However, my answer to your question is a different one: Different tasks
require different tools. Limiting yourself to one tool based on one use case
is not a good decision.

If I only need a simple use case and there's a choice of a tool that is
technically superior, only with a complicated user interface and a tool that
is technically inferior but with a simple user interface I loose the moment I
pick the superior tool. A complicated user interface makes me memorize and
learn more, making the whole handling more tedious and error prone than
required. I'd pick the simpler tool any day if it fits. I'll go for the more
elaborate one when the need shows itself. The tricky point is choosing the
right tool, but that works both ways. A powerful tool may be dangerous as well
and cost you a finger, hand or more. A simple tool well under your control may
bring you much farther with less injuries.

For example: Have you ever tried teaching non-developers (i.E. designers) the
full git user interface with all it's powers? I usually get about as far a the
subset that's equivalent to what svn can do before they nod me off. Github's
simple gui client that can only talk to github repositories is what most folks
that I know need and are content with. So if that's all they need and all they
use, why should they opt for a more complicated piece of software. To them
it's all "oh, I can store stuff there" and I can actually related to that.
They'd be happy with svn and they'll never move beyond that. The only reason
they switched is because github offers such a nifty image comparison view.

~~~
felipec
> This is a false assumption and a flawed comparison. An SSD has the same
> external interface as a spindle disk. It does have does have different
> internal properties though that make it superior in almost all use cases
> though.

Wrong. If SSDs are superior in every way, why do spin disks still exist?
Because SSDs are way more expensive for the same size, and don't have as much
storage.

And you are ignoring the point by focusing on SSDs and not the point being
made.

> I actually have to admit that after reading the whole comment thread in your
> blog, I'm actually convinced that the HG folks won the argument.

Oh really? Can you point to the comment in which they answer to my challenge?
Or do you feel that evidence is not important?

> However, my answer to your question is a different one: Different tasks
> require different tools. Limiting yourself to one tool based on one use case
> is not a good decision.

Fallacy of hasty generalization. Sometimes it's better to pick the tool
depending on the job, sometimes you should specialize in a certain tool. For
example, there's not much point in picking a different editor for different
tasks.

A more succinct example is saying; limiting to one tool, your hands, is not a
good decision. Well, you can use your feet for some tasks if you want, the
rest of the world would prefer hands any time for most tasks.

> For example: Have you ever tried teaching non-developers (i.E. designers)
> the full git user interface with all it's powers? I usually get about as far
> a the subset that's equivalent to what svn can do before they nod me off.

Have you? And were they already familiar with SVN? That's the problem, you are
not even aware you are making an assumption; that SVN is the natural way to to
SCM, and thus mercurial's UI is good because it resembles SVN.

As I mentioned in my blog post; some people claim they find git easier to
learn, particularly the ones that don't know SVN, or were tainted by crap like
CVS. IOW; they don't _relearn_.

~~~
Xylakant
> Wrong. If SSDs are superior in every way, why do spin disks still exist?
> Because SSDs are way more expensive for the same size, and don't have as
> much storage. And you are ignoring the point by focusing on SSDs and not the
> point being made.

Well, I guess we're running in circles. My point was: I can swap a spindle
disk of the same size with an ssd of the same size and reap all the benefits
without changing anything beyond that. You can't swap tools that use different
(if similar) underlying concepts in that way. (That's still oversimplifying in
the case of disk.)

> Oh really? Can you point to the comment in which they answer to my
> challenge? Or do you feel that evidence is not important?

Yes, really. And evidence was provided by both sides and it all comes down to
a judgement call, a personal estimate which feature or which mental model
seems more preferrable to you. It's a bit like vi vs emacs. Both are certainly
capable and do have demonstrable advantages over the other but in the end it's
a matter of which feature matters most to you.

> A more succinct example is saying; limiting to one tool, your hands, is not
> a good decision. Well, you can use your feet for some tasks if you want, the
> rest of the world would prefer hands any time for most tasks.

Well. You do have a knack for flawed comparisons. It's like saying "Limiting
yourself limiting to one tool, a screwdriver if you're trying to drive in
screws is not a good decision. Well, you can always use a hammer for some
screws, but the rest of the world would prefer using a screwdriver for most
screws." My point is not "pick the least fitting tool for any task you find."
but rather "have a sledgehammer and a carpenters hammer ready." You don't want
the sledgehammer to hang up a picture, but you'd not want the carpenters
hammer to drive in a pole either.

> Have you? And were they already familiar with SVN? That's the problem, you
> are not even aware you are making an assumption; that SVN is the natural way
> to to SCM, and thus mercurial's UI is good because it resembles SVN.

Yes I have. Multiple times. And some were familiar with svn and some where
not. However, nowhere did I say that they preferred hg over git nor am I
making any assumption that there even exists something such akin to a natural
way to do SCM.

I argue that for their use cases the _feature_ set of what svn can do is
wholly sufficient. They don't do branching and they don't do merging since PSD
files merge so awfully bad even with git. The couldn't care less about svn's
need to hit the network for pretty much every operation since the central
repository is inside the same gigbit LAN and will never move. They want
mandatory locking in the repository for their word files so that person A can
indicate "hey, I'm working on that document". And I hope we can agree that for
the set of features that is supported by svn, svn offers the simpler mental
model and also the simpler user interface. It does away with all that local
repository and only knows a local working copy and a centralized remote
storage. You can push changes to the remote and pull updates from there. And
if that's all you ever need, svn might be the natural choice. Or maybe
perforce. Or alienbrain. If your uses go beyond that, well, then it isn't. And
then it's maybe git. Or darcs - which does have some very nifty features of
it's own.

As a side note: mercurials UI is superior to git's not because it resembles
svn's but for one singe major reason: It's consistent where git's is not.

Example: git uses the sometimes the full verb (git add, commit, ...) and
sometimes an abbreviation (git rm). This probably stems from the fact that
"rm" is the unix command to remove files and in line with what the usual unix
developer would expect, but it's not internally consistent. HG always uses the
full verb (hg add, hg remove). Git knows (add, remove, move) but not (copy).
Git knows "git submodule add" which is a simple operation but the reverse is
an arcane invocation that requires you to modify two config files and may as
well trash your repository if executed wrong. None of this is related to svn
or the svn user interface.

~~~
felipec
> My point was: I can swap a spindle disk of the same size with an ssd of the
> same size and reap all the benefits without changing anything beyond that.

And what does that point has to do with anything?

> Yes, really. And evidence was provided by both sides and it all comes down
> to a judgement call, a personal estimate which feature or which mental model
> seems more preferrable to you.

Wrong. It's not a judgement call, I mentioned specifically for which cases git
branching is superior, and I constructed a challenge to show that git is
superior in that case and _NOBODY_ answered the challenge. Conversely,
_NOBODY_ provided a case for the opposite; that mercurial's branching is
superior in _any_ case.

It's very simple; you can do more with git branching than with mercurial
branching. Period.

> Well. You do have a knack for flawed comparisons. It's like saying "Limiting
> yourself limiting to one tool, a screwdriver if you're trying to drive in
> screws is not a good decision.

Completely irrelevant. You can't get out of the hasty generalization fallacy
by pointing out a case in your favor. Yes, sometimes proficiency in more tools
is better, but not _ALWAYS_. Just like yeah, in some cases black people like
chicken, but not _ALWAYS_.

> The couldn't care less about svn's need to hit the network for pretty much
> every operation since the central repository is inside the same gigbit LAN
> and will never move.

Assumptions, assumptions, assumptions.

> As a side note: mercurials UI is superior to git's not because it resembles
> svn's but for one singe major reason: It's consistent where git's is not.

There have been calls for suggestions for improvement, including radical
changes since years. _NOBODY_ has ever suggested to replace 'rm' with
'remove'; it's not an issue.

If you want to talk about _real_ consistency issues, how about branches vs
bookmarks vs anonymous branches. In git they are all branches.

------
yeswecan
Let us not forget that GitHub is a _major_ reason why people choose Git. If
Bitbucket (or a hypothetical HgHub) had taken the larger market share first,
we'd likely see more projects using Hg than Git.

~~~
Xylakant
Full ack. Github and it's widespread usage is actually the only reason I
switched over to git as my main VCS. Close to 100% of my usual use-cases would
be well-served by a recent version of svn. I know, there's a ton of use-cases
that benefit tremendously from git's model, but those are not mine.

I still hate how the raw cli interface with tons of switches forces me to
learn git's internals and storage model. Git advocates usually tell me "you
need to know to unleash the powers of git" but actually, I'd rather prefer not
to know and regard it as an opaque tool.

Compared to svn or hg the cli feels crude and not well thought over either.
There's commands that accept the full verb (add, diff, checkout, clone),
others that accept an abbreviation (rm, mv), but no (remove, move). I can set
that up using aliases, I know. But why do I have to? Then there's add, move
and remove, but no copy (which is "cp <file>; git add <file>). I often find
myself typing the wrong incantation because there's a mismatch in how the
commands are named. In that respect svn really shines in comparison.

~~~
stevecooperorg
The internal representation aspect is important -- specifically, having to
deal with the index as separate from both your working directory and your
repository. that makes it harder to get started.

------
natmaster
Mercurial having an extension to make their branches like git is exactly why
Mercurial is superior. I love git branches, but everything else about it is
worse, but that's OK because I just use the extension like everyone else.
Mercurial has great extensibility, which means if you need to do anything not
simple, it lets you.

As they say, simple things should be simple, complex things should be
possible. Mercurial is the best of both worlds.

~~~
felipec
No, there's no extension in mercurial that makes branches behave like git
branches. That is clear in the 160 comments where I even created a challenge
for anyone to try to do the same in mercurial, and curiously, people have
criticized my videos, scripts, and every little thing possible, but _none_
have actually shown how it's possible to do the same in mercurial.

So no, you can't do the same, that's the whole point. If you think you can,
you are most likely mistaken, but feel free to show how in the comments of the
blog, and expect a prompt rebuttal.

------
BerislavLopac
To me, it's obvious that the author has entered the comparison with a very
strong git bias, so it is only naturally that git won eventually.

He is right on one thing: the differences are mostly subtle, the most glaring
one being whether history is allowed to be rewritten or not. In the end it all
comes down to personal preferences, and my personal experience is strongly in
favor of hg.

~~~
parfe
>To me, it's obvious that the author has entered the comparison with a very
strong git bias, so it is only naturally that git won eventually.

Was it obvious because he specifically notes it in the intro to the article?

 _Note: I’m a long-time advocate of Git, and a contributor to the project, so
I am biased (but I hope my conclusions are not)._

~~~
eslaught
The author seems to contradict himself in a comment[1]: _My objective is to
show why Git is superior._ (Thanks to [2] for noticing.)

[1]: [http://felipec.wordpress.com/2011/01/16/mercurial-vs-git-
its...](http://felipec.wordpress.com/2011/01/16/mercurial-vs-git-its-all-in-
the-branches/#comment-5773)

[2]: <http://news.ycombinator.com/item?id=3437677>

~~~
felipec
It's not a contradiction. Note the word _why_. If in the analysis it turns out
I fail to show that git is indeed superior, I would have to agree mercurial is
superior, or they are equal.

That was not the case.

------
198d
This was a really bad comparison/argument for git. Anyone actually trying to
decide between the two should just forget everything you've read and start
with a different source.

That aside, I've used both over the last 3 years (2 in git; 1 in hg) and
although I prefer git, hg is a fantastic tool. I think the largest difference
between the 2 is usability. I do believe hg is quite a bit easier to pick up.
It does a really good job of, by default, making sure you don't shoot yourself
in the foot and also keeps you further away from the 'nitty-gritty'. Git, on
the other hand, allows you to do whatever you want and generally makes the
assumption you always know what you're doing. The details are not very far
down from the surface and it's easy to get yourself in trouble if you don't
know what you're doing.

Personally I prefer git because I feel so close to the metal, but there's
certainly a perfectly valid argument to choose hg over git.

------
eipipuz
Felipe Contreras, do you really not see your bias at selecting the example you
chose? Paragraphs before you mention how in Mercurial "History is Sacred" then
you push for that.

~~~
felipec
I did not mention "history is sacred", Google did, in his analysis.

And I didn't pick any example, as I _clearly_ said; they are basically the
same, the _only_ real difference is in the way they deal with branches, and
obviously, I concentrated on the _difference_.

------
Uchikoma
Blog posts that use "crush" should not be taken serious.

