Live data from Hacker News

Prefer mercurial to git

lists.gnu.org

31–40 of 189 posts

Re: Prefer mercurial to git

#31

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…

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.)

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

Re: Prefer mercurial to git

#32

Earlier quoted context omitted.

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

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.

Re: Prefer mercurial to git

#33
post #25
post #6

You should have linked the first post in that thread. It explains what the whole thing is actually about: https://lists.gnu.org/archive/html/emacs-devel/2014-01/msg00... Tl;dr: Mercurial is a free software project sharing GNU's goals, while Git is made by anti-GNU people who do not believe in free software and has an incompatible license.

Summary of main arguments: Jordi Gutiérrez Hermoso: [...] main argument in favour of hg is not technical, but rather social. For GNU, I think it is far more important to support a project that aligns with GNU's aims [...] GPL2+ Reply by Eric S. Raymond: +1. And I say that as someone who *likes* hg and wishes it had won. Repeating the bzr mistake would be stupid, stupid, *stupid*. Edit: Raymond replied to Kastrup who…

That's not an accurate summary of the main arguments. For one thing, on the pro-hg side you've quoted only the opinion of someone (Jordi Gutiérrez Hermoso) who isn't even an emacs dev: the email starts with a note to please cc him on replies because he isn't subscribed to the list! This isn't the view of the GNU project, the opinion of the Emacs developers on why they prefer hg over git, or even the personal view of RMS. You'll get a better summary if you read the thread.

Re: Prefer mercurial to git

#34
post #22

I've been meaning to do a blog post about this for a while, but I've tried both, and so far, I prefer Git because of the way it treats branches. Git seems far friendlier to the workflow of just doing stuff, and deciding how you want to commit it later. In Git, it's easy to work for a while, then decide you have 3 commits worth of changes, and one of them really ought to be in its own branch, and commit it all like th…

That's only true for named branches. You can create an unnamed branch in hg simply by going to a point in the history (what Git would call detached head) and committing.

That said, the handling of named branches remains a pain point, and at this point I would recommend people just go with Git despite the steeper learning curve.

Re: Prefer mercurial to git

#36
I use Git and Mercurial daily. They're both ok. However.. I prefer Git to mercurial, mainly because:

- Git is noticeably faster for all operations (yeah, specially if you don't use GitHub for pull/push as they're slow as hell ;-)

- Git has sensible default settings, for example, git log is easier than hg log|less. Similarly, git show HEAD^ is easier than hg log --patch --rev tip. (Both are easier to remember, type, and keep the logic across the tool).

- Finally, Git handles everything in a generic fashion. Want to make a test branch and play around? git branch blahtest and play. With hg, you have to use queues, and weird commands such as qpop, qremove, qseries, qnew <= this is very confusing to newcomers. Basically, I feel like Git knows how to KISS better than Mercurial.

Re: Prefer mercurial to git

#37
post #6

You should have linked the first post in that thread. It explains what the whole thing is actually about: https://lists.gnu.org/archive/html/emacs-devel/2014-01/msg00... Tl;dr: Mercurial is a free software project sharing GNU's goals, while Git is made by anti-GNU people who do not believe in free software and has an incompatible license.

A slight exaggeration, but yes, that's quite close to the OP's argument (Git is GPLv2 and will not change; Hg is GPLv2+ and therefore closer in spirit to GNU's goals and a GNU project like Emacs should favor GPLv3 and AGPL tools).

Luckily, that particular argument is thoroughly rebutted downthread. Choice quote: "Emacs shot itself in this foot already" by choosing Bzr, GNU's blessed VCS, for such political reasons. (Worth noting: RMS raised no strong objections to Git.) Also, the OP is called out for not understanding the driving reasons for moving Emacs to Git.

Edit: Corrected reference to Hg's license; it's GPLv2+, not GPLv3.

Re: Prefer mercurial to git

#38
post #15
post #7

My biggest issues with hg are that hg's revision numbers aren't synchronized across instances, they are local only[1] making them kind of useless, you can't easily have local branches[2], and it stores changesets instead of objects. I've ever seen a convincing argument to choose hg over git. Sure you can do a lot of things with it and I'm sure it's perfectly fine to use, but if you know git, and you like git, there's…

> What does hg have that makes it better than git that you should give up git? Better user experience out of the box for Windows shops. This might change with Microsoft's adoption of git for TFS, but you won't find many appraisals for git at my workplace. Many people still miss hg.

The place I'm currently working is (sadly) a Windows shop, and we've never had any issues using msys-git.

Some of us use TortiseGit for logs, diffs, etc (we used to use TortiseSVN pretty much exclusively before we moved)

Re: Prefer mercurial to git

#39

Earlier quoted context omitted.

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

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"

Re: Prefer mercurial to git

#40
post #2

Context? This just seems to be a post from a Mercurial/Hg advocate. Mercurial could be 10% better than git, but unless it's 500% better, it will never displace it.

or it could be 10% lesser than git. arguably, feels 50% slower. ;-)
Post reply on HN