Git's Killer Feature (why it's better than Mercurial) | Hacker News Reader

Git's Killer Feature (why it's better than Mercurial)

codemac.net

17 pointsnickb12 comments

I see that Git has indeed advanced, sexier concepts than Hg. However there is one thing that makes me uncomfortable with Git: Its source code is a bit like the Linux kernel: written in C, messy, with lots of scripts (including Bash and Perl scripts). Mercurial's is written in Python. As an Ocaml hacker, I do not like Python much; however I think a tool such a VCS ought to be written in a higher-level language than C, even if that means Python. How are we going to be sure that the Git code doesn't contain nasty buffer overflows? If Python does not give static type safety, at least it shields against segmentation faults.

Generally you would hope a project is written in whatever the author(s) excel(s) at. I think that Linus and Co have clearly demonstrated they have a lot of experience doing C correctly, so you should have some faith that they know what they are doing.

They might not have similar aptitude with Ocaml or Python. Given enough time, all bugs are shallow, and Git is becoming popular enough that this becomes true. After all, Python itself was also written in C, so it is theoretically at risk to the same things.

They certainly are expert C coders and a VCS can benefit from direct-to-the metal code. Let's hope that lower-quality C won't creep in.

(I obviously meant "Given enough eyes, ..." above. Not sure what my brain is doing today, but translating thoughts to keystrokes is definitely not working correctly.)

It's easy to write horrific code in any language, high or low level. From what I've seen, both the Linux kernel and git are clean and very readable. In general, I'll take well-written C over poorly-written Python (I'm not implying anything about Mercurial here) or poorly-written OCaml.

Git has historically had a few bugs with some high-level commands not correctly reacting to errors in lower-level commands, but they have been largely squashed in recent releases. The low-level commands have always been pretty solid, and the git repository format has been stable for a long, long time now.

So in summary, I wouldn't be too concerned about the implementation language of choice. It's always about the maker, not about the tools.

You could always re-implement Git in OCaml, Haskell, or whatever other language you might like.

Linus has addressed this:

http://thread.gmane.org/gmane.comp.version-control.git/57643...

Yes but it's a C++ vs C argument and I certainly wouldn't advocate C++ for anything. What would be more appropriate I think is a type-safe high-level language with garbage collection, where you can at least concatenate strings and forget about it for most of the code, save maybe the lower-levels in pure C.

Interesting. I'd never heard of "git add -i" before. I missed that feature from Darcs.

Isn't this exactly like "hg record"?

do you get something similar in e.g. Darcs?

you do. the interactive commits was one of the features I missed from Darcs

Reply on news.ycombinator.com