Source control for all dmd source (Git propaganda =)

[Yigal Chripun]

Jérôme M. Berger wrote:
> 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

disclaimer: I'm a git user, mainly on Unix but also on windows.

It seems to me from reading the above that this is not a fair and 
objective comparison. you're saying that A is better than B just because 
you are used to A.
more specifically, git's command line structure of:
git <global options> <cmd> <cmd options> is more organized than what you 
describe in mercurial.
saying that "Mercurial command names are much more intuitive (especially 
coming from cvs/svn)" is also misleading since git has a completely 
different conceptual model that IMO should not try to fit with CVS 
concepts. If that is really a big issue for you just set up aliases in 
.gitconfig with your preferred command names (I was a subversion user 
myself and initially did exactly that)
colored output - you didn't even try to enable it in git (which is 
trivial) but you have written a patch to do the same for mercurial.

I have no problem with your preference to use mercurial, just don't 
claim that git is not ready to be used on windows because of that 
preference.