Jérôme M. Berger wrote:
Leandro Lucarella wrote:I've started. I'll give you a full report tomorrow when I have tested it more completely.Why don't you test it and stop talking about what you think it's going on and start talking about what's *really* going on.It doesn't seems very fair to discard something just because you have thefeeling that it wouldn't work well (specially when other people use it andsay it works well).
Okay, here goes. For those who don't want to read the whole text, here's the short version: - Git has one nice feature that Mercurial doesn't have yet, and that's the staging area; - Git isn't ready for production use on Windows. If you want to use it, go ahead but don't go crying if something goes wrong (the details are in the "Status" section below); - Git's command are not very intuitive (especially coming from CVS or SVN), which makes it difficult to start using it (no matter how easy you may find it later on); - Git's built-in help system is pretty bad: it is difficult to find the information you want and instead of giving you the information, git will start a web browser to display it.
And here's the long version:
Introduction
============
I've run a quick comparison of Git and Mercurial on Windows. The
tests consisted of importing a Subversion repository with 364
revisions, then running some standard commands: help, clone, log,
status, diff, commit.
Git version used: 1.6.3.msysgit.0Mercurial version used: 1.2.1 + custom patch to enable coloured output on Windows.
Install ======= Ok, no problem. Git has made a lot of progress here. Import from svn ===============Git is sloooowwwww (a couple of hours to import, Mercurial did it in about five minutes). But then you don't import an SVN repository everyday, so speed isn't that much of an issue here (actually I only imported that svn repository to have some real life data rather than testing on a mostly empty artificial repository, not to test SVN import per se).
Help ====Git's help is unusable. It took me way too long to find out how to revert the changed files so that the working folder reflects the content of the repository and how to update the files to a specific version.
Git launches a web browser instead of giving me the info I want directly. I then need to close the browser window or go back to the shell before I can continue. Plus, if I need to check on something, I need to switch back and forth between the browser and the shell instead of simply scrolling the shell window.
While I wouldn't be against a command/option to start the browser, the default behaviour should be to print the info directly in the terminal.
A nice thing about Mercurial: I can type either "hg help cmd" or "hg cmd help" to get help. Git only recognizes the first form.
Clone ===== Command syntax is the same. Git took 57s where Mercurial only took 17s. Log ===Mercurial can identify a changeset with a simple number (valid only in the current repository), a short hash (valid anywhere so long as there are no collisions) or a long hash. The default behaviour is to only show the number and short hash, which is much more user-friendly. From what I could tell, git only uses long hashes?
Default log output is much more readable in Mercurial:- Like I said above, changeset numer + short hash is easier to identify than full hash; - The different changesets are immediately identifiable. In git, it is not easy to see where the info for one commit ends and the next begins;
Clock time: 1.1s for Mercurial, 1.4s for Git. Status ======Git reported some modified files immediately after the clone and even though I hadn't changed anything and the files were identical to the original folder, in which Git didn't report any modified files. I was unable to fix it so that "status" reported no changes (even deleting the files and checking them out again didn't fix it).
The problem is probably due to incorrect handling of line endings, but I have been unable to determine the precise conditions that make it manifest on those files and not others. This does not exactly fill me with confidence for Git's reliability as a whole.
- Time for an empty status report: 1s for Mercurial, 1.1s for Git;- Time for a status report with an added unknown file: 0.4s for Mercurial, 1s for Git (obviously, we have reached the precision of my timing method);
- Time for a status report with a changed file: 1s each. Commit ====== Git has three ways to commit files to the repository: - Commit everything with "git commit -a"; - Commit only some files with "git commit file1 file2...";- The staging area. This allows you to specify which files (or which changes) you want to commit using "git add" before doing the actual commit with "git commit". This is nice for some complicated situations, but I feel that it is not that common.
Mercurial currently only supports the first two ways. Reflections are in progress to add the third way, but they want to design the UI properly before implementing it: http://www.selenic.com/mercurial/wiki/IndexesExtension
General Remarks ===============I found the Mercurial command line much easier to use than Git's. For example:
- Mercurial and Git both have global options which apply to all commands and specific options that only apply to the current command. With Mercurial, the options may be put in any order, and in particular, you can do "hg cmd <options>". With Git the global options must be put before the command and the specific options must be put after: "git <global options> cmd <specific options>";
- Mercurial accepts either "hg help cmd" or "hg cmd help". Git only accepts "git help cmd";
- Mercurial command names are much more intuitive (especially coming from cvs/svn). For example, in order to return a modified file to its repository state: "cvs revert", "svn revert", "hg revert", "git checkout". Even in absolute terms, "checkout" is not the first word that comes to mind, I would have understood "revert" (obviously), "restore", "backout" or an extra option to "update" (which Git doesn't have anyway).
- Default Git behaviour is to send command output to a pager. Default Mercurial behaviour is to simply send it to the terminal. I personally prefer Mercurial's way, but this can be argued either way. Anyway, it is possible to change the default.
The speed difference isn't that big or important for most operations, except for clone.
Mercurial is also slightly better in terms of disk space used, although this does not mean much given the capacity of today's HDDs.
Git is supposed to have coloured output, but it wasn't enabled by default and I didn't try to find how to do it. Mercurial has coloured output on Unix, but not on Windows (I have written a patch to allow it to work on Windows but I haven't sent it upstream yet).
Conclusion ========== Git weak points:- speed (although most common operations are fast enough that it shouldn't really be a problem except for "clone");
- unintuitive command names; - poor help system;- inconsistent behaviour of the status command which may hide other more serious problems.
Git strong points:- the staging area is a nice feature with no Mercurial equivalent (although they're working on it). But I wouldn't call it a killer feature.
Note that all my tests were done on Windows. It is quite possible that the speed and inconsistent behaviour issues would not occur on Unix, but they are enough to justify my claims that Git doesn't really work on Windows.
Jerome
--
mailto:jeber...@free.fr
http://jeberger.free.fr
Jabber: jeber...@jabber.fr
signature.asc
Description: OpenPGP digital signature
