

Git vs. Mercurial analysis - onli
https://www.robertnitsch.de/notes/git_vs_mercurial_analysis

======
eridius
I'm only a couple paragraphs in, but there's already some pretty heavy bias
here that's turning me off from continuing.

First off, the recommendation right off the bat is (paraphrased) "Companies
should use Mercurial because it's easier to learn, which translates to saving
time and money". Even if I accept that it's easier to learn, this completely
ignores any consideration about interoperability with existing open source
projects that you may or may not need, or the existence of any tools built
around git or mercurial that you may want to use. The learning curve is but
one factor that should be taken into consideration; it is not the _only_
factor.

Secondly, the very first actual comparison between the two is highly
disingenuous. It makes a claim about the documentation for `git commit` vs `hg
commit` using what it _says_ the summary of each command is. But that's not
the summary. That's just the first line of the in-depth documentation. The
actual summary of both commands, which is the very first real line of text you
see in the help on both, is as follows:

    
    
        git-commit - Record changes to the repository
    

pretty straightforward. And for `hg commit`:

    
    
        commit the specified files or all outstanding changes
    

Also pretty straightforward. But these lines have been completely bypassed in
order to provide a comparison that uses more technical language on the part of
git and therefore is perhaps less understandable for a nontechnical user.

\---

If we continue onwards, we find more absurd comparisons. There's a nice little
ding against git here for actually listing its options in the synopsis, which
is standard behavior for unix utilities, unlike hg which just says
`[OPTION]...`. Sorry Robert, but git definitely wins that one.

And then he goes on to complain about terminology used in the description of
`git checkout`, such as "working tree", even though these terms are well
defined for git and are used consistently in all documentation (definitely a
plus). But he doesn't mind terminology used in `hg update`, such as "working
directory" or "changeset". You can't do an objective comparison between two
VCS's learning curve unless you're willing to actually assume the user has no
prior knowledge of the VCS. Big fail on Robert's part. And it's enough to make
me stop reading here.

~~~
onli
I understand why you see it that way. +1 to the "learning curve is not the
only factor". But a few remarks:

> There's a nice little ding against git here for actually listing its options
> in the synopsis, which is standard behavior for unix utilities, unlike hg
> which just says `[OPTION]...`. Sorry Robert, but git definitely wins that
> one.

I'm not so sure about that. I think i have seen both pretty often. Example:
man sed. I understood his point there: The git-way of the presentation makes
it harder to understand the basic structure of the command, which is an issue
given the multiple forms they can have.

> The actual summary of both commands, which is the very first real line of
> text you see in the help on both, is as follows: ...

True with the first line, not necessarily true with what is the real
description/summary here. Gits placement is ambiguous (that line is called
name).

> But he doesn't mind terminology used in `hg update`, such as "working
> directory" or "changeset

Well, both words are used in other places than mercurial, they are the basic
words for what they are...

------
gemma
This isn't an analysis of Git vs. Mercurial, this is an analysis of Git's
documentation vs Mercurial's documentation. Disappointing.

------
jabbernotty
Just a quick note -- if you don't want to make an exception for the
certificate, you can go to the page over http.

~~~
needsch
Another quick note: The certificate is signed by CACert.org, a community-
driven Certificate Authority (<http://www.cacert.org>).

