Mercurial vs git

Fri Jan 5 00:48:45 UTC 2007

List members,

We have decided to move to a distributed VCS and based upon ease of use, portability, and suitability for the task, I have recommended Mercurial.  Another developer has been looking at git and has raised some concerns about Mercurial.  I was hoping for some informed responses.  Thanks in advance.

----------- his note to me follows ----------

Just took another look, I find no equivalent in Hg to the following git commands that I find very useful:

git branch -d       : REMOVES all history of a branch, doesn't just mark it dead. Allows trimming repository, removing experimental stuff that was useless without bloating the repo, etc.

git merge -squashed  : brings a range of commits from one branch onto another as a SINGLE commit. among other things, this allows backing out objects (e.g., large binaries incorrectly checked in) before merging such that they never show up in the main repo keeping its size down.

git diff -diff-filter=MRC -name-status : in < 0.1 second on my machine, tells me the name of every file that was changed between two branches or commits.

gitk                    : a really useful history browser

git-cvsserver       : provides cvs-client access to a branch

I just did a full checkout of version.419 on my linux box, < 1 second. Perhaps Hg is as fast, I don't know. git is definitely a speed daemon compared to CVS or svn.

Hg still has non-sense about move, rename, add, delete. git just tracks what is there. If something is simply moved, the SHA has on contents are the same, so the "move" is implicitly recognized. git also tries (very hard) to identify moved files when looking at new stuff, and to id copies, etc. without the user having to bother. Basically, git accepts the directory tree as it exists as what you want, rather than needing a bunch of "add-this, remove that, move this to there" type commands. (e.g., git commit -a just takes the current directory tree as it is and checks it in, less anything new that matches a pattern in .gitignore, the latter you have to add explicitly but this keeps us from inadvertently adding binaries, etc. that shouldn't go in).

That is just a start. I am really impressed by the richness of the commands available to git, given my history of having to write my own programs to do a lot of stuff around CVS, and looking and realizing Hg provides much less than git, I just don't want to go there. I LIKE that git has a lot more functions. It doesn't mean everyone needs to use them all, but it does mean I can find a way to do everything I've so far thought we need to do and I cannot do so with Hg.

----------- an earlier message from him follows --------------- 

I have to say I tried hg, and found it a) slow compared to git, b) gave a larger repo size than did git, c) doesn't have a lot of the commit / merge / squash functionality I really want, and d) just generally found it inferior to what I found with git. (git is advancing rapidly, almost every comparison table or blog I've found that states "git doesn't do x" or git's repo is inefficient, or . is wrong). Also, Linus is not the maintainer of git, and if you follow the mailing list (I have for a month, it is VERY active, over 100 emails per day from developers) you will find an extreme bias towards making it easier to use with a number of changes made in that direction that override Linus' early decisions. So, I am not worried on this score. Hg started just slightly after git, and for the same reasons as git (loss of bitkeeper for the Linux kernel developers). Hg moved more rapidly due to development in Python, but has a much smaller development crowd so far as I can see. I could be wrong of course. Python is many things, it isn't fast: it even loses to Matlab for many programming tasks and we know Matlab is slow.

That is why I decided against Hg. However, we can look again. My early impression of Hg vs git steered me toward the latter, perhaps I didn't give Hg enough of a chance.

---------- my original message ------------

Although, I believe that git would be a reasonable solution for our distributed version control needs, I think that Mercurial should be considered:

*	trivial to set up, available for Windows, Linux, Solaris, BSD, Mac 
*	apparently, a good bit easier to use than git 
*	used by the XenWorks (Xen) projects and OpenSolaris 
*	git's use for Linux, may actually be a detriment - it will continue to be targeted to providing the type of support that Torvalds wants - which may not be optimal for other types of projects.  In other words, a feature convenient for general project management, could very well be nixed if Torvalds has the least inkling that it might possibly slow him down. 
*	extensions and import and export hooks are really slick and easy to develop - a unix2dos/dos2unix hook is part of the standard package.  Keyword expansion could be done with the hooks, if still needed 
*	the codebase is in Python (except for one speed-critical component).  The code is much smaller and easier to hack (if needed), but it provides the speed of git 
*	repositories are much smaller than with git 
*	handles email patch exchange, like git

Disadvantages:

*	 Deleting history not quite present in current version.  However, there are workarounds and the issue is high on the priority list (there is a patch, but it is not in the stable version yet).  See the "I committed a change containing nuclear launch codes, how do I delete it permanently?" section of the FAQ (http://www.selenic.com/mercurial/wiki/index.cgi/FAQ <http://www.selenic.com/mercurial/wiki/index.cgi/FAQ> ).

Other References:

http://www.selenic.com/mercurial/wiki/ <http://www.selenic.com/mercurial/wiki/>  (Mercurial homepage)

http://sayspy.blogspot.com/2006/11/bazaar-vs-mercurial-unscientific.html <http://sayspy.blogspot.com/2006/11/bazaar-vs-mercurial-unscientific.html>  (Mercurial vs Bazaar)

http://lwn.net/Articles/151624/ <http://lwn.net/Articles/151624/>    (Mercurial: an alternative to git)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20070104/0b3c7183/attachment-0001.html>