Source control for all dmd source (Git propaganda =)

["Jérôme M. Berger"]

Jérôme M. Berger wrote:
> Leandro Lucarella wrote:
>> 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 the
>> feeling that it wouldn't work well (specially when other people use it 
>> and
>> say it works well).
>>
>     I've started. I'll give you a full report tomorrow when I have 
> tested it more completely.

	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.0
Mercurial 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:jeberger at free.fr
http://jeberger.free.fr
Jabber: jeberger at jabber.fr

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20090603/4bb4f27e/attachment.pgp>