

Fanning the flames of the Git vs. Mercurial debate - zain
http://blog.zacharyvoase.com/post/147813314/why-mercurial-git-or-how-i-learned-to-stop-censoring

======
johnbender
"Applications written in higher-level, dynamic languages (like Python and
Ruby) are always going to be more ‘intelligent’ than those written in low-
level, static languages (like C and Java)."

He positions this as a given, and moves on with his only justification being
that websites feel "smoother to use" when written with Django or Rails.

"One has nearly 10 times as many files, and 10 times as many lines of code as
the other. Can you guess which one?"

In addition to being snarky, I think the lines of code written as a metric for
software quality is as about as useful as selling software with "smoother to
use" printed on the box.

~~~
zacharyvoase
Actually, the justification is given later on: tools like these, which do a
lot of the commonly-repeated work for you, make it easier for you to focus on
the purpose of your application as opposed to overcoming the limitations of
the tool itself.

~~~
evdawg
Zack, I'm directing this straight at you since I see you're the author of this
post.

Honestly, posts like this are just detrimental to both communities. They're
immature and show a complete lack of understanding of software development.
Choosing the right tool for the job is rarely easy as "high level" and "low
level".

Git was created to solve a specific need: Distributed development of the Linux
kernel. The fact that it's been adopted by so many developers outside of the
Kernel community shows that it is at _minimum_ an adequate tool for the job.
I'd go ahead and say, for those developers, Git > Mercurial. That's why they
choose it.

For the developers who choose Mercurial, Mercurial > Git. That's why they've
chosen Mercurial.

Please, before you publish stuff like this, remember that we're all on the
same team. Next time, advocate Mercurial by talking about how it's improved
your workflow. Talk about why Mercurial is better than Git for _you_ , perhaps
talk about the technical differences of the underlying implementations on a
conceptual level.

That way, maybe you could help someone make an informed choice about what to
use, instead of basing their decision on something as silly as the language
it's written in.

~~~
silentbicycle
Contributing patches is an option, too. There's a shortage of people in the
open source world who are good at UI design.

------
oconnor0
I never get these Git vs. Mercurial debates. I don't see why they matter. Pick
something you like & are comfortable with & can use well - and then learn that
tool well.

Linus certainly doesn't care if you think Mercurial's better than Git. He
doesn't agree. He wrote a tool to help him manage the Linux kernel source
trees, something it does well. His goals never have been making the most
elegant or intelligent software, but making good software that works. And it's
a strategy that's succeeded.

And the Mercurial devs probably think the same regarding Git.

As an aside, I wonder what would have happened had not Linus popularized
distributed version control systems. I doubt we'd even be having this
discussion. I certainly hadn't been exposed before hearing about the BitKeeper
debacle.

~~~
tdavis
Exactly. I am a _huge_ Python fan and have contemplated giving Mercurial a go
just because I know I could hack it myself if need be and that'd be cool. But
I've gotten to the point where I know my way around Git well enough that I
can't justify it. Besides familiarity with the commands, I've also gotten used
to the workflow, which I'm sure differs under Mercurial.

~~~
ubernostrum
"I've also gotten used to the workflow, which I'm sure differs under
Mercurial."

Yes and no.

The workflow for managing branches is different, because you usually just
clone an hg repo to do a branch, and then merge as needed.

The workflow for more complex things isn't quite as different as most people
seem to think, though; mainly the difference is that in hg the answer is "use
a patch queue". Operations on patch queues are somewhat lower level than, say,
git's rebase, but all the power is still there (and there's a rebase extension
which will let you do it all in one go if that's your thing).

What's been interesting to me is seeing the evolution of the "popular" git
workflow over time. Originally, people hyped things like rebasing and editing
commit history, but gradually the emphasis has shifted away from that and the
best practices have solidified around using those features only when they're
necessary, which is much less often than a lot of folks originally believed.
And, amusingly, that's _very_ close to the way hg has always been used: you
_can_ do lots of fancy stuff, but you should have a good reason for doing so
(and should typically never do so after you've pushed to other folks or
they've pulled from you).

------
dexen
From the fine article:

    
    
        In a spirit of irony, ohcount has been rewritten from Ruby to C.
    

Wasn't it the whole point of high level languages to be able to prototype
quickly, and then perhaps re-write selected parts in lower level for better
performance and portability? This even happened to Hg; parts of it (diff,
IIRC) got implemented in C later on for better performance.

~~~
silentbicycle
Actually, a pretty big feature of high-level languages is being reminded _over
and over_ that you never need to re-write the vast majority of most programs.
For many tasks, two lines of awk or half a page of Python is quite sufficient.
(And when something is a legitimate hotspot and benefits from being rewritten
in C, it's not _selling out_. Where the heck did that idea come from?)

------
gruseom
What puts Git in a class of its own is the astonishing efficiency of its
implementation. It is one of those rare instances where a quantitative
difference becomes a qualitative one and in my opinion makes Git an
engineering masterpiece.

Obviously this is related to its being a C program. The OP's error in
comparing code sizes is the implicit assumption that all other things are
equal.

------
tolmasky
Under this bullet-proof logic the best applications would be written in
AppleScript (spoiler alert: they're not).

Seriously though, the idea that Linus designed a sub par interface for git
because he was _sooo_ busy mallocing and freeing is laughable.

------
ubernostrum
I just like hg because it has -- in my opinion -- a saner interface and a more
useful branch strategy for the types of stuff I'm usually doing.

The fact that it has a good Python API (courtesy of being written in Python)
is a nice bonus.

~~~
johnbender
This could be included in a list of more acceptable arguments for Hg. Along
with a list of interface comparisons for common actions that points to a
"saner interface", an explanation of the branching strategy differences would
make for a blog worthy article.

------
hyperbovine
Clearly the guy who wrote this has never had to deal with a corrupted repo
before. I have never used Hg but it happened to me enough times in Subversion
to convince me to switch to Git. The lines of code metric is silly. How about
who /wrote/ those lines? I'm very happy entrusting my version control to the
same guy who wrote my operating system, thank you.

~~~
garnet7
How would git be better at dealing with (or avoiding) a corrupted repo than
hg?

------
zacharyvoase
A lot of the commenters need to read <http://www.paulgraham.com/avg.html> (the
section titled 'The Blub Paradox' is particularly relevant, but the entire
essay is fantastic). In addition, the concepts of essential complexity and
accidental complexity are addressed quite comprehensively in Fred Brooks'
essay 'No Silver Bullet' (Google it).

------
321abc
Just use bzr instead.

