Hacker News Reader

Comment by spellboots | Hacker News Reader

I was forced to use mercurial for a few years at work and I really hated it. Sure it has a better learning curve than git (or did) but I found it to be incredibly frustrating already knowing git.

In addition, I found it to be slower, less flexible, and prone to permanent repository corruption - yes, in git you do see repo corruption but because of the cryptographic nature of git objects you know immediately. HG will (did?) happily let you work away at a corrupted repo for weeks until a fresh clone was attempted and the dreaded repo corrupted message killed development for days until the problem was painstakingly manually fixed.

This is just personal experience and a lot of it comes down to taste, but IMO if you are already proficient with git there is absolutely nothing about mercurial that is preferable and some considerable downsides I have been subjected to.

Disclaimer: This was a few years ago now, perhaps the project is more mature than it was.

View on HN

I can relate to these comments because when I was a Git user forced to use Mercurial for Firefox development, I initially thought much of the same. I have since come around [1].

Mercurial has come a long way in the last few years. While I used to see repo corruption semi-frequently, I have not seen it once in the last year or so. This can be attributed to bug fixes and less reliance on mq. mq is a giant hack on top of Mercurial's storage model and there were many corner cases in older Mercurials where mq could lead to repo corruption. I use the experimental evolve extension now, but I can't yet recommend that to the masses because it's very rough around the edges. Hopefully in the next 6-12 months.

I strongly disagree with the statement that Mercurial is less flexible than Git. I find Mercurial to be more flexible. If you don't take my word for it, ask Facebook [2]: "Our engineers were comfortable with Git and we preferred to stay with a familiar tool, so we took a long, hard look at improving it to work at scale. After much deliberation, we concluded that Git's internals would be difficult to work with for an ambitious scaling project." The article goes on to describe some key areas where Mercurial is more flexible.

Some things possible in Mercurial that aren't with Git:

* Extending the wire protocol. Git's wire protocol is the exchange of objects (key-value pairs) and refs to said objects. Mercurial's is command-based and you can have client and server talk their own commands.

* Revision sets [3]. Extremely useful feature. See [4] for how I've used this as Mozilla.

* Phases. Mercurial knows when you are changing a published and should-be-immutable changeset/commit and by default prevents you from footgunning yourself.

* Changeset evolution. The mindset about "pushing rebases is evil" has its roots almost completely in limitations of tools. Changeset evolution removes that limitation.

As I wrote at [1], I believe the future of Mercurial is bright. Don't discount Mercurial because of past experiences with ancient versions or because you assume the Git way is the only and right way.

[1] http://gregoryszorc.com/blog/2013/05/12/thoughts-on-mercuria... [2] https://code.facebook.com/posts/218678814984400/scaling-merc... [3] http://www.selenic.com/hg/help/revsets [4] http://gregoryszorc.com/blog/2013/11/08/using-mercurial-to-q...

Maybe it's just me, but recommending a DVCS because it hasn't corrupted your data lately is like recommending a car because it hasn't had the wheels randomly fall off lately.

The parent's recommendation was not based upon data not being corrupted lately. He stated that this issue is not as prevalent as it used to be, countering the commentor's slightly outdated experience, and then went on to list off features as the basis of his recommendation.

> but I found it to be incredibly frustrating already knowing git.

From my understanding, the terminology and behavior of Mercurial is more in-line with other SCMs out there (like SVN), while Git seems to do things a bit differently. A lot of it is terminology differences or default behavior for various commands.

> I found it to be slower, less flexible,

Mercurial should be about the same speed as Git now adays. I'd be interested to hear what parts of HG you thought were slow. Also, for flexibility, Mercurial disables a lot of more advanced features by defaults (anything that could get a developer in trouble or mess with history). All of the extensions that ship with Mercurial are officially supported and can be used if you want that functionality.

> prone to permanent repository corruption

I'd be interested to hear if you ever found out what caused your problems. Mercurial has a page talking about this [0].

> IMO if you are already proficient with git there is absolutely nothing about mercurial that is preferable and some considerable downsides I have been subjected to.

For almost all features, I'd totally agree. There are 3 things in Mercurial that I see as an advantage over Git. (1) named branches (every commit on the branch will be tagged with the branch name). (2) LargeFile[1] extension for handling very large files you don't want people having to pull, though this breaks DVCS concepts. (3) A future feature that looks really promising, ChangesetEvolution[2], that will basically allow history rewriting that can be pushed to others.

[0] http://mercurial.selenic.com/wiki/RepositoryCorruption

[1] http://mercurial.selenic.com/wiki/LargefilesExtension

[2] http://mercurial.selenic.com/wiki/ChangesetEvolution

Funny, at my company it is the oppositive.

If you give the developers the choice, they would drop git and go back to mercurial.

Then why not switch to mercurial?

I don't know the specifics of his case, but there could be several reasons.

A likely one is that the benefits of a switch wouldn't outweigh the costs, at least not within a reasonable timeframe.

Another is that there may not be resources to dedicate to such an effort, even if the return would be suitable.

And yet another could be management buying into all of the git hype we've been subjected to a lot lately. Git (and GitHub) today are like Ruby on Rails was a few years back. Even though there are several alternatives, some of them much better in some ways, they just don't get the media attention, and thus don't get hyped, and thus don't get onto the radar of managers who decide which VCS to use, and thus don't see as much use, and thus aren't even seen as viable options by said managers.

You got it almost right.

We do enterprise consulting and are bound to the technology that is already in place. In 90% of our projects we seldom introduce anything new.

Many of our customers have been sold into git hype and have been moving or have recently moved to git.

Because as enterprise consultants we use what the customers require, it is not up to us to choose our tooling.

Many of those customers have been sold to git hype before getting us on board.

There are some cases where customers don't know what tooling they require though ;)

True, but not on my area of work. That is seldom the case.

I'm interested in your comment about the cryptographic nature of git objects. I know that hashes are used to identify commits, but I'm not sure how Git uses cryptography elsewhere — e.g. to check the integrity of repos, as you said. Can you explain this aspect in more detail? (Not being argumentative; just curious.)

Committers are able to sign their commit with their GPG key.

Edit: I was wrong and changed all the words

Not by default it isn't. And git uses GPG, not SSH keys.

You're right, I was wrong. I'm sorry.

Everything about this comment is wrong. Commits are never signed [EDIT: it is possible since 2011, but rarely used; thanks zobzu]. Annotated tags can be signed via PGP (not SSH keys), but the public key is not stored in the repository (unless you put it there manually, as with the tag "junio-gpg-pub" in git.git, which is not even Junio's current signing key). In practice, people obtain keys from PGP keyservers.

I can't reply to a child of this comment, but yes, this comment is entirely wrong. However, Git can indeed sign commits (using gpg), not just tags. "git commit -S"

http://mercurial.selenic.com/wiki/GpgExtension

Every object in the repository, including commits and trees, is hashed via SHA-1. Commits also include the SHA of the previous commit, so if you verify each commit, then compare the SHA at the top to the "correct" one, then that means your entire repository is valid.

> Every object in the repository, including commits and trees, is hashed via SHA-1. Commits also include the SHA of the previous commit

mercurial does pretty much the same, as far as I know.

> so if you verify each commit

But surely that does not happen on every CLI operation does it? So you only find out about corruption when all the repository is traversed and checked, which will usually be explicitly or on clone. Thus the same as hg.

actually, it's possible to execute clone in git without it checking. If you do a local clone, it will happily hand you a broken repo.

In git a commit is basically the root of a Merkle Tree[1], i.e. every reference is the sha1 sum of the object being referenced. If you take a commit apart what you see is a commit message, a hash of its parent commit and a hash of a tree object. That tree object itself contains hashes of file objects and tree object as well as their corresponding names. Thus assuming you would want to tamper with a file of a commit this files hash would change and therefore the parent tree objects hash would change and therefore the commit hash would change. So the complete state of the repository is cryptographically secured with just the hash of the commit object. You can find out more about git innards here: http://git-scm.com/book/en/Git-Internals-Git-Objects

To be fair: I believe mercurial commits enjoy the same level of protection, although via different means.

[1] https://en.wikipedia.org/wiki/Merkle_tree

> So the complete state of the repository is cryptographically secured

It should be noted, however, that Linus and others specifically disclaim that this is a security mechanism:

"Git uses SHA-1 in a way which has nothing at all to do with security.... It's just the best hash you can get.... It's about the ability to trust your data." --Linus (http://en.wikipedia.org/wiki/SHA-1#Data_integrity)

And in the midst of a discussion about how only professional cryptographers should design crypto, pretty much everyone insists that Git is not crypto (see replies to: https://news.ycombinator.com/item?id=6961683)

To be honest I don't buy his argument. If it is not about security, why not use md5? It is faster after all and gives you the same protection against accidental data corruption as sha1. And if he cared about security then he should have chosen sha256 or sha512, the latter of which is even faster than sha1 on 64bit systems [1] and can be truncated if you think it is too long.

And really there is no denying that git relies on the security of sha1, especially its second preimage resistance[2]. Otherwise all the signed Linux releases would be useless, because you could exchange the files in the release with your own, malicious ones. Even collision resistance is important, as if you are a rogue kernel developer you can craft two files with identical hashes: One that passes scrutiny upstream and one that has a subtle backdoor. If it is in one those binary blobs there is a very low chance of it ever being found.

My guess is that he did not really put more than 5 minutes of thought into the decision. He has a track record of mediocre understanding of and low regard for cryptographic topics, see for example: http://thread.gmane.org/gmane.linux.kernel/1173350/focus=117... .

[1] http://bench.cr.yp.to/results-hash.html

[2] You cannot find another file with the same hash as the given file.

I am not sure I buy it either. To me it comes off as cognitive dissonance between the party line of "don't invent your own crypto" and the pervasive love and acceptance of Git.

No one wants to say that Git, on which many of our SCM processes are now built, is suspect. But also no one wants to argue that Linus is somehow an exception to the rule against amateur cryptography.

So what we're left with a somewhat ambiguous situation where Git is described as not being crypto despite the fact that in practice people assume it is resistant to malicious attack.

> Git is described as not being crypto

Git has plenty of crypto in it, namely GPG (for signing tags), SSH and SSL (for transport). Using off-the-shelf crypto like this doesn't strike me as "inventing your own crypto".

> people assume it is resistant to malicious attack

Exactly what's the threat model here? I can't conceive of a malicious attack that exploits gits reliance of on SHA1 as a message digest that doesn't also require write access to your filesystem.

I think your argument stems from the fact that SHA1 is deemed insecure and therefore anything associated with it must also be insecure. As I said in the previous thread, git doesn't use SHA1 to make any of the guarantees that cryptography is typically used to make.

It's usage is to prevent accidental corruption in the everyday usage of git (the sort that mercurial appears to have been prone to in the past), not to protect against a malicious adversary with write access to the filesystem.

> It's usage is to prevent accidental corruption in the everyday usage of git (the sort that mercurial appears to have been prone to in the past), not to protect against a malicious adversary with write access to the filesystem.

I have evidence that people in practice use it to protect against just this sort of thing: https://news.ycombinator.com/item?id=7003900

> Exactly what's the threat model here? I can't conceive of a malicious attack that exploits gits reliance of on SHA1 as a message digest that doesn't also require write access to your filesystem.

Write access to your filesystem is a threat git is supposed to be secure against (more precisely: the filesystem of your git server) as Haberman has pointed out. Another incident this was relevant is the kernel.org hack: http://www.linuxfoundation.org/news-media/blogs/browse/2011/...

Furthermore, the signed tags are completely worthless if you assume second preimage resistance of sha1 to be broken. Imagine I sit between kernel.org and your computer. When you download the next Linus blessed Linux release I manipulate some of the files to contain some backdoor while still having the same sha1. As you will certainly not check every file manually for bogus content you happily compile and run the manipulated kernel and I have access to your PC via my planted backdoor.

Intel is adding native SHA instructions to x86... so sha1 will probably be much faster on those CPUs.

http://en.wikipedia.org/wiki/Intel_SHA_extensions

Interesting…

Note that they also add sha256 specific instructions. Which is good, because sha1 should no longer be used for new application and existing application should definitely start looking into an update path. See [1] for a rough estimate how fast the existing (publicly known) attacks become feasible.

I hope they are also working on implementing the sha3 permutation. That would allow for some really cool features to be super fast and simple like authenticated encryption or reseedable pseudo random number generation[2].

[1] https://www.schneier.com/blog/archives/2012/10/when_will_we_... [2] For details see section 5 and 6 of https://eprint.iacr.org/2011/499.pdf

> To be fair: I believe mercurial commits enjoy the same level of protection, although via different means.

Actually they have almost exactly the same Merkel tree (there are some minor differences in the metadata that is included, mercurial also includes the file level parents while git does not, for example).

The inspiration came from Monotone.

It's worth noting that Git's hashes guard against accidental corruption; they aren't widely thought to be strong against attack by an intelligent adversary.

That's true, and AFAIK Linus says much the same. SHA1 is used for practical purposes and not security in the face of a determined attacker with cryptanalytic ability.

Most people prefer what they already know (learning any new system or process is always frustrating because you are attempting to map concept rather than learn concepts - square peg, round hole).

I prefer (and use) git myself, but it took awhile (and much of my developer/friend network to go first) for me to commit to the switch from subversion...my main issue was that subversion worked well enough for what I needed/wanted at the time. I didn't really switch until it became harder to work with others because of my subversion use and easier to work with others if/when I adopted git.

git is as prone to bitrot as hg.

git doesn't run fsck on the entire repo for each operation, and unless you fsck or clone you won't detect corruption for quite a while.

it's exactly the same for hg, which is built on the same hashing concept as git (actually the other way round, as hg came first).

Mercurial was announced on 2005-04-19 and git on 2005-04-07, so no Mercurial was not first.

Edit: Monotone is older than git though.

I think we can state they weren't copying each other.

Indeed, they both were developed separately as a reaction to the BitKeeper drama.

I think both started on the same day (due to both authors being part of the kernel "kabal" and already in the known about the upcoming bk debacle).

Mercurial was usable earlier though ;-)

(the first git versions were really really low level, and did not include features like packs, while hg had high kevel command line and its compressed storage format from the first release)

Moreover, Mercurial's storage scheme is built on append-only files, whereas Git periodically repacks its objects, which means that Mercurial actually has fewer opportunities for cosmic rays to hit the bits while they are in motion, and so less chance of corruption.

Most bit rot isn't due to cosmic rays, but rather to decay on the disk itself.

Apparently, decay on the disk itself is sometimes caused by cosmic rays:

http://docs.oracle.com/cd/E19253-01/819-5461/gbbym/index.htm...

I've been using mercurial and git for about 8 years and I've never had corruption problems from either. What are you doing to get corruption errors. Also, mercurial hashes just like git and has for a long time. Are you sure that's not enough to detect corruption issues?

I personally find git staging to be a major inconvenience and would rather not have it around.

my first run with git also got me a corrupted repo. never got support for it.

but this os pointless, the keyword in your post is "forced".

Reply on news.ycombinator.com