Subject: Git at Better SCM Initiative comparison of VCS (long)

From: Jakub Narebski <[email-masked]>
Date: Wed, 1 Oct 2008 20:45:13 +0200

I think that the information about Git at Better SCM Initiative
comparison of various version control systems

  http://better-scm.berlios.de/comparison/comparison.html

used also for versioncontrolblog "Version control systems comparison"

  http://versioncontrolblog.com/comparison

needs a few corrections.

Therefore below you can find proposed changes, as discussed here on
this mailing list (this time CC-ing author of Git entry, Alexey
Mahotkin of versioncontrolblog).  For each section (each compared
feature) I have put description, entry for one or more open source
distributed version control systems (for reference) and current entry
for Git, in email-quote like format (prefixed with "scm> "), then
proposed corrected entry (if it needs correction) and some comments
about it.

Contrary to previous post in this thread I did not comment this time
on the comparison itself, for example not well defined criteria, and
lack of tests or functional/use case description which would help to
check if SCM supports given feature.

I think this could be basis for Alexey to send corrections to
Better SCM comparison table.

Please comment

scm>         <timestamp>
scm>             $Id: scm-comparison.xml 322 2008-08-09 05:47:26Z shlomif $
scm>         </timestamp>

Here just so you know on which version it is based on.

scm>     <section id="repos_operations">
scm>         <title>Repository Operations</title>
scm>         <section id="atomic_commits">
scm>             <title>Atomic Commits</title>
scm>             <expl>
scm>                 Support for atomic commits means that if an
scm>                 operation on the repository is interrupted
scm>                 in the middle, the repository will not be
scm>                 left in an inconsistent state. Are the
scm>                 check-in operations atomic, or can
scm>                 interrupting an operation leave the
scm>                 repository in an intermediate state?
scm>             </expl>
scm>             <compare>
scm>                 <s id="cvs">No. CVS commits are not atomic.</s>
scm>                 <s id="bazaar">Yes. Commits are atomic.</s>
scm>                 <s id="mercurial">Yes.</s>
scm>                 <s id="git">Yes. Commits are atomic.</s>
scm>             </compare>
scm>         </section>

No comment here (beside the fact that table neds some unification, but
this is hardly the case for Better SCM comparison Git entry maintainer).

scm>         <section id="move">
scm>             <title>Files and Directories Moves or Renames</title>
scm>             <expl>
scm>                 Does the system support moving a file or directory to
scm>                 a different location while still retaining the history
scm>                 of the file? <b>Note:</b> also see the next section
scm>                 about intelligent merging of renamed paths.
scm>             </expl>
scm>             <compare>
scm>                 <s id="bazaar">Yes. Renames are supported for files and directories.</s>
scm>                 <s id="mercurial">Yes. Renames are supported.</s>
scm>                 <s id="git">
scm>                     Renames are supported for most practical
scm>                     purposes.  Git even detects renames when a file has been
scm>                     changed afterward the rename.  However, due to a peculiar
scm>                     repository structure, renames are not recorded
scm>                     explicitly, and Git has to deduce them (which works well
scm>                     in practice).
scm>                 </s>
scm>            </compare>
scm>         </section>

I would propose to change it to something like the followig:

  Renames are supported for most practical purposes[1]. By design Git
  does heuristic <i>rename detection</i> (based on similarity score of
  pathnames and file contents), instead of doing rename tracking.  This
  approach allows for more generic content tracking of code movement
  (which usually happens much often than wholesame file renaming),
  e.g. in "git blame -C -C".

  Footnotes:
  [1] "git log --follow <i>filename</i>" works only for very simple
      history currently; rename detection can get confused by empty files
      and files consisting mainly of boilerplate (e.g. license text).

Comments:

I am a bit unsure about need for footnote.  Perhaps it should be simply
removed.  Also, perhaps instead of "Renames are supported..." it should
be "File renames are supported...", although it looks like it would
improve soon: see thread on git mailing list about detecting wholesale
firectory renames (with ability to track directory splitting, like now
git is able to track contents movement across files).

scm>         <section id="intelligent_renames">
scm>             <title>Intelligent Merging after Moves or Renames</title>
scm>             <expl>
scm>                 If the system keeps tracks of renames, does it support
scm>                 intelligent merging of the files in the history after
scm>                 the rename? (For example, changing a file in a renamed
scm>                 directory, and trying to merge it).
scm>             </expl>
scm>             <compare>
scm>                 <s id="bazaar">Yes. Renames are intelligent.</s>
scm>                 <s id="mercurial">
scm>                     No. <a 
scm>                         href="http://hgbook.red-bean.com/hgbookch5.html#x9-1030005.4">the
scm>                         Mercurial book says:</a>
scm>                     "When you use the 'hg rename' command, Mercurial makes a 
scm>                     copy of each source file, then deletes it and marks the
scm>                     file as removed. "
scm>                 </s>
scm>                 <s id="git">
scm>                     No. As detailed in the <a
scm>                         href="http://git.or.cz/gitwiki/GitFaq#rename-tracking">Git
scm>                         FAQ</a>:
scm>                     "Git has a rename command git mv, but that is just a
scm>                     convenience. The effect is indistinguishable from removing
scm>                     the file and adding another with different name and the
scm>                     same content."
scm>                 </s>
scm>            </compare>
scm>         </section>

This entry is incorrect[1]; it has to be changed to something like the
following proposal:

  Yes, Git can deal with renamed files during merging, thanks to rename
  detection.

Comments:

Git does apply change to renamed file, both if file itself is renamed,
and if directory it is in gets renamed (like in example in feature
description).  What Git _currently_ doesn't support (at least for now,
with lack of detection of directories as a whole; this might change
soon) is with adding new files to the renamed directory: if one side
renamed directory and second side added new files in the old directory,
those new files would show at old name, not at new name.

There also might be two kinds of problems: first, if you are merging
old and/or much diverged branch rename detection can use much of CPU
power even if there are no renames present (this happened once or
twice).  Second, if similarity based rename detection fail you would
not get conflict and will be left with two versions of a file in
working directory; this might happen for example if you renamed some
'sensitive' binary file (so small change results in large change in
representation) or change is too large compared to whole contents of 
a file.  In second case it is expected that requested from time to time
advisory rename tracking would help.

Hmmm... I wonder if the above problems with rename detection happen
more often than problems with, usually file-id based, rename tracking
used by other SCM.

Footnote:
=========
[1] It looks like we really need http://git.or.cz/gitwiki/FileRenames

BTW. I wonder if Mercurial entry isn't incorrect either...

scm>         <section id="copy">
scm>             <title>File and Directories Copies</title>
scm>             <expl>
scm>                 Does the version control system support copying
scm>                 files or directories to a different location at the
scm>                 repository level, while retaining the history?
scm>             </expl>
scm>             <compare>
scm>                 <s id="bazaar">No. Copies are not supported.</s>
scm>                 <s id="mercurial">Yes. Copies are supported</s>
scm>                 <s id="git">No.  Copies are not supported.</s>
scm>            </compare>
scm>         </section>

I would write that:

  Copies detection is supported, but for performance reasons it is not
  enabled by default.

Comments:

Perhaps we could mention here that there are two thresholds of copying
detection: checking only changed files and --detect-copies-harder. Also
worth of note might be the fact that git-blame has support for
detecting code copying, also across filenames.

scm>         <section id="repos_clone">
scm>             <title>Remote Repository Replication</title>
scm>             <expl>
scm>                 Does the system support cloning a remote repository to get
scm>                 a functionally equivalent copy in the local system? That 
scm>                 should be done without any special access to the remote 
scm>                 server except for normal repository access.
scm>             </expl>
scm>             <compare>
scm>                 <s id="mercurial">Yes.</s>
scm>                 <s id="git">Yes.  This is very intrinsic feature of Git.</s>
scm>             </compare>
scm>         </section>

In fact this is 'very intrinsic feature' of each distributed SCM...
In short: I think that simple 'Yes.' answer for Git would be better.

scm>         <section id="push">
scm>             <title>Propagating Changes to Parent Repositories</title>
scm>             <expl>
scm>                 Can the system propagate changes from one repository to 
scm>                 another?
scm>             </expl>
scm>             <compare>
scm>                 <s id="mercurial">Yes.</s>
scm>                 <s id="git">Yes.  (The Linux kernel development process uses this extremely often).</s>
scm>             </compare>
scm>         </section>

Again I think that simple "Yes" would be sufficient.  The sentence in
parentheses doesn't bring any new information, so IMHO should be
removed.  Especially that Linux kernel uses also patch based wokflow 
very extensively.

scm>         <section id="permissions">
scm>             <title>Repository Permissions</title>
scm>             <expl>
scm>                 Is it possible to define permissions on access to different
scm>                 parts of a remote repository? Or is access open for all? 
scm>             </expl>
scm>             <compare>
scm>                 <s id="bazaar">
scm>                     Basic access control can be implemented through a
scm>                     contributed hook script.  ACL support for the
scm>                     Bazaar server is planned.
scm>                 </s>
scm>                 <s id="mercurial">
scm>                     Yes. It is possible to lock down repositories,
scm>                     subdirectories, or files using hooks.
scm>                 </s>
scm>                 <s id="git">
scm>                     No, but a single server can serve many repositories.
scm>                     Also, UNIX permissions can be used to some extent.
scm>                 </s>

Line-wrapped for better readibility.

scm>             </compare>
scm>         </section>

I think the answer should be here:

  Yes. It is possible to lock down repositories, branches, 
  subdirectories, or files using hooks (see for example
  <a href="">contrib/hooks/paranoid</a> example hook).

Comments:

Shawn, could you _please_ make documentation of 'paranoid' contrib hook
complete by documenting how to configure it to lock down directories
or files?

As the feature seems to be more about fine-grained access control 
(by the way something that Karl Fogel in his "Prodicting OSS..." book
is against, as better solved by socual and not technological means)
I have not mentioned here things like web server permissions for WebDAV
access, UNIX file permissions, or tools like Gitosis or ssh_acl, which
are about access to repository as a whole.

scm>         <section id="changesets">
scm>             <title>Changesets' Support</title>
scm>             <expl>
scm>                 Does the repository support changesets? Changesets are a way
scm>                 to group a number of modifications that are relevant to each
scm>                 other in one atomic package, that can be cancelled or 
scm>                 propagated as needed.
scm>             </expl>
scm>             <compare>
scm>                 <s id="darcs">
scm>                     Yes. Changesets are supported.
scm>                 </s>
scm>                 <s id="mercurial">
scm>                     Yes. Changesets are supported.
scm>                 </s>
scm>                 <s id="git">
scm>                     Yes, Changesets are supported,
scm>                     and there's some flexibility in creating them.
scm>                 </s>

Line wrapped for better eradibility.

scm>            </compare>
scm>         </section>

In my opition, such an _empty_ addition ("there's some flexibility in
creating them") is totally unnecessary; it adds no solid information
(what does it mean "some flexibility") and should be removed.

I think the entry should simply state "Yes. Changesets are supported.";
see for example entry for Darcs (from which Iu the idea of having
"git add --interactive" was taken from).

Comments:

Description of this feature is not entirely clean, but I think
everybody knows what it meant to mean.

scm>         <section id="annotate">
scm>             <title>Tracking Line-wise File History</title>
scm>             <expl>
scm>                 Does the version control system have an option to track the
scm>                 history of the file line-by-line? I.e., can it show for each line
scm>                 at which revision it was most recently changed, and by whom?
scm>             </expl>
scm>             <compare>
scm>                 <s id="mercurial">Yes. (hg annotate)</s>
scm>                 <s id="git">Yes. (git blame).</s>
scm>            </compare>
scm>         </section>
scm>     </section>

This is O.K, but I wonder if it wouldn't be worth to add information
about unique (as far as I know) git-blame abilities, something like:

  Yes.  (git blame).

  <a href="">git-blame</a> can be asked to detect moving lines in file
  and between files; there exist GUI for blame ("git gui blame <file>").

Comments:

One would suspect that because Git is based towards whole project
history, and not per file history, git-blame is slow.  To migitate
that there is incremental blame mode used to reduce latency in graphical
blame viewers like "git gui blame", contrib/blameview, or the one
in QGit.

But anegdotical evidence (meaning in this case discussion with Pieter
de Bie of vcscompare blog on #git IRC channel) shows that git-blame
is of similar performance that its equivalent in Mercurial and Bazaar.
(It is hard to compare with "cvs annotate" as for centralized SCM there
is matter of network speed; I don't know how it compares for local
access, i.e. repository and file/client on the same filesystem).

scm>     <section id="features">
scm>         <title>Features</title>
scm>         <section id="work_on_dir">
scm>             <title>Ability to Work only on One Directory of the Repository</title>
scm>             <expl>
scm>                 Can the version control system checkout only one directory of
scm>                 the repository? Or restrict the check-ins to only one 
scm>                 directory?
scm>             </expl>
scm>             <compare>
scm>                 <s id="bazaar">For checkouts: No. For checkins: Yes.</s>
scm>                 <s id="mercurial">
scm>                     It is possible to commit changes only in a subset of the
scm>                     tree. There are plans for partial checkouts.
scm>                 </s>
scm>                 <s id="git">
scm>                     No.  However, commits could be restricted somewhat,
scm>                     see the "Repository Permissions".
scm>                 </s>

Again, re-wrapped for better readibility.

scm>            </compare>
scm>         </section>

I'm not sure if the entry for Git shouldn't read as:

  No. All changes are made repository-wide.

as in for Aegis.  On the other hand it is possible to restrict commits
and remote access to only some subset of the tree using hooks; also
there is work done on implementing partial/sparse checkout for Git by
Nguyễn Thái Ngọc Duy (pclouds).  So perhaps it should read instead,
similarly to what we have for Mercurial:

  It is possible to restrict commit via hooks to changes only in
  a subset of the tree. Implementing partial/sparse checkouts is
  work in progress.

Comments:

Again, as said in "Producting OSS..." it is better to implement such
restrictions using social rather that technical means; at least for
checkins; there are some reasons (disk space, protecting against
accidental changes, <insert your reason here>) for partial checkouts.

scm>         <section id="tracking_uncommited_changes">
scm>             <title>Tracking Uncommited Changes</title>
scm>             <expl>
scm>                 Does the software have an ability to track the changes in the
scm>                 working copy that were not yet committed to the repository?
scm>             </expl>
scm>             <compare>
scm>                 <s id="mercurial">Yes. Using hg diff.</s>
scm>                 <s id="git">Yes.
scm>                     Also, branches are very lightweight in Git, and
scm>                     could be considered a kind of storage for "uncommitted" code
scm>                     in some workflows.
scm>                 </s>

A bit rewrapped, and indented.

scm>             </compare>
scm>         </section>

Perhaps we should add "Using git diff" here; the problem is with
[possible] difference between "git diff", "git diff HEAD", and
"git diff --cached".

I also think that the comment is not on subject; it is not closely
related to described feature, so it should be IMHO abandoned. The entry
should then read:

  Yes. Using git diff. 

Comments:

I don't think it is worth mentioning the fact that staging area in Git
(the index) is explicit and visible, and can be directly accessed. In
usual [newbie] workflows "git diff" works just fine...

scm>         <section id="per_file_commit_messages">
scm>             <title>Per-File Commit Messages</title>
scm>             <expl>
scm>                 Does the system have a way to assign a per-file commit message
scm>                 to the changeset, as well as a per-changeset message?
scm>             </expl>
scm>             <compare>
scm>                 <s id="bitkeeper">Yes. It is possible to have a per-file
scm>                     commit message</s>
scm>                 <s id="mercurial">
scm>                     No.
scm>                 </s>
scm>                 <s id="git">
scm>                     No. Commit messages are per changeset.
scm>                 </s>

Re-wrapped.

scm>            </compare>
scm>         </section>
scm>     </section>

Perhaps simple "No." as in case of Mercurial entry would be enough here?

Comments:

What is the reason somebody would want per-file commit message?  They
cannot be terribly useful, as BitKeeper which taught Linus about
distributed version control has it, but Git doesn't.

scm>     <section id="technical_status">
scm>         <title>Technical Status</title>
scm>         <section id="documentation">
scm>             <title>Documentation</title>
scm>             <expl>
scm>                 How well is the system documented? How easy is it to
scm>                 get started using it?
scm>             </expl>
scm>             <compare>
scm>                 <s id="darcs">
scm>                     Good. The manual contains a brief tutorial and a solid
scm>                     reference.  Every sub-command can print its usage.
scm>                     Because the command-set is small and the model is
scm>                     simple, many users find it easy to get started.
scm>                 </s>
scm>                 <s id="git">
scm>                     Medium. The short help is too terse and obscure.
scm>                     The man pages are extensive, but tend to be confusing.
scm>                     The are many tutorials.
scm>                 </s>

Re-wrapped and re-indented for better readibilit.

scm>             </compare>
scm>         </section>

That of course depends on ones opinion.  I would say "Good", now that
there is "Git User's Manual" distributed with Git, and now that there
started semi-official "Git Community Book" (http://book.git-scm.com).

So I would say:

  Good. There is extensive <a href="">"Git User's Manual"<a/> distributed
  with Git. There started semi-official <a href="http://book.git-scm.com">"Git
  Community Book". There is manpage for each sub-command, and most commands
  can print short usage.

Comments:

Backward compatibility^W^W Old impressions die hard,... And the meme
that git documentation is not user friendly is difficult to kill.

scm>         <section id="ease_of_deployment">
scm>             <title>Ease of Deployment</title>
scm>             <expl>
scm>                 How easy is it to deploy the software? What are
scm>                 the dependencies and how can they be satisfied?
scm>             </expl>
scm>             <compare>
scm>                 <s id="mercurial">
scm>                     Excellent.  Binary packages are available for all
scm>                     popular platforms.  Building from source requires
scm>                     only Python 2.3 (or later) and a C compiler.
scm>                 </s>
scm>                <s id="git">
scm>                    Good.  Binary packages are available
scm>                    for modern platforms.  C compiler and Perl are
scm>                    required. Requires cygwin on Windows, and has some
scm>                    UNIXisms.
scm>                </s>
scm>            </compare>
scm>         </section>

Thanks to msysGit project it is not required to install Cygwin to have
Git on Windows. Also some commands are still written as shell scripts.
So I would say:

  Good. Binary packages are available for modern platforms. On Windows
  one can use either Cygwin, or native msysGit version. Requires Perl
  and POSIX shell (and assorted shell tools) for some commands.

Comments:

I don't know what to do with "has some UNIXisms"; I think it is not
very relevant for this entry, and it shouldn't be here.

As I use Git only on Linux (and at one time used msysGit on MS Windows XP
and FAT filesystem on USB drive to fetch git.git only), I cannot say much
on ease of deployment on other operating systems, like Free/Open/NetBSD,
MacOS X, different Unices, and MS Windows.  Perhaps it should be even
"Very good" here?

scm>         <section id="command_set">
scm>             <title>Command Set</title>
scm>             <expl>
scm>                 What is the command set? How compatible is it with
scm>                 the commands of CVS (the current open-source defacto
scm>                 standard)?
scm>             </expl>
scm>             <compare>
scm>                 <s id="bitkeeper">
scm>                     A CVS-like command set with some easy-to-get-used-to
scm>                     complications due to its different way of work and 
scm>                     philosophy.
scm>                 </s>
scm>                 <s id="bazaar">
scm>                     Tries to follow CVS conventions, but deviates
scm>                     where there is a different design.
scm>                 </s>

The same for Mercurial.

scm>                 <s id="git">
scm>                     Command set is very feature-rich, and not compatible
scm>                     with CVS.
scm>                 </s>
scm>            </compare>
scm>         </section>

I don't think the situation is that different than with Mercurial, so
perhaps it should simply read:

  Tries to follow CVS conventions, but deviates where there is
  a different design.

Although Git doesn't "try to follow CVS conventions", it does follow
BitKeeper convention, then transitively also CVS conventions.  I would
agree with "feature-rich" comment, though ;-)

So perhaps something like

  Command set is very feature-rich; compatibility with CVS conventions
  are limited by differences in design.

scm>         <section id="networking">
scm>             <title>Networking Support</title>
scm>             <expl>
scm>                 How good is the networking integration of the system?
scm>                 How compliant is it with existing protocols and infra-structure?
scm>             </expl>
scm>             <compare>
scm>                 <s id="bazaar">
scm>                     Excellent. Works natively over HTTP (read-only),
scm>                     FTP and SFTP without having Bazaar installed at
scm>                     the remote end.  Works over HTTP, SSH and a custom
scm>                     protocol when talking to a remote Bazaar
scm>                     server. Supports RSYNC and WebDAV (experimental)
scm>                     through plugins.
scm>                 </s>
scm>                 <s id="mercurial">
scm>                     Excellent.  Uses HTTP or ssh.  Remote access also
scm>                     works safely without locks over read-only network
scm>                     filesystems.
scm>                 </s>
scm>                 <s id="git">
scm>                     Excellent.  Can use native Git protocol, but works
scm>                     over rsync, ssh, HTTP and HTTPS also.
scm>                 </s>

Line-wrapped for better readibility.

scm>             </compare>
scm>         </section>

It could be written differently, but basically is O.K. Perhaps we
should state explicitely which protocols are read-only, and which allow
to push (publish) changes to server; which protocols require Git
installed on server and which can do without; perhaps also git-bundle
for off-line transport could be mentioned here.

scm>         <section id="portability">
scm>             <title>Portability</title>
scm>             <expl>
scm>                 How portable is the version-control system to various 
scm>                 operating systems, computer architectures, and other
scm>                 types of systems?
scm>             </expl>
scm>             <compare>
scm>                 <s id="mercurial">
scm>                     Excellent. Runs on all platforms supported by
scm>                     Python.  Repositories are portable across CPU
scm>                     architectures and endian conventions.
scm>                 </s>
scm>                 <s id="perforce">
scm>                     Excellent. Runs on UNIX, Mac OS, BeOS and Windows.
scm>                 </s>
scm>                 <s id="git">
scm>                     The client works on most UNIXes, but not on native
scm>                     MS-Windows. The Cygwin build seems to be workable, though.
scm>                 </s>

Re-wrapped for better readibility.

scm>             </compare>
scm>         </section>
scm>     </section>

There is native MS Windows implementation named msysGit. We can also
mention that Git runs on Linux, Free/Open/NetBSD, various Unices, 
MacOX X.

The entry for Git lacks also single word descriptions, like "Excellent",
"Very good", "Good", "Medium", that most other SCM have in this part
(and "Windows only" for some).

So I would say something like the following:

  Very good. Works on Linux, FreeBSD, MacOS X and various Unices. Works
  on MS Windows either via Cygwin, or natively via msysGit.

Perhaps I would also add the following cautionary note:

  There are some issues with case-insensitive (e.g. FAT) or filename-mangling
  (MacOS HFS+) filesystems, but they can be worked around.

Comments:

I'm not sure if it should be "Very good" or "Excellent" here. I think
that this section is about number of systems SCM was ported to, not
how hard is to make it work (port Git) on some additional OS. I'm not
sure how complete msysGit is (git-svn and other Perl scripts), so I put
"Very good"; but it is improving, buth thanks to builtinification and
to efforts of msysGit maintainers and developers.

scm>     <section id="user_interaces">
scm>         <title>User Interfaces</title>
scm>         <section id="web_interface">
scm>             <title>Web Interface</title>
scm>             <expl>
scm>                 Does the system have a WWW-based interface that can be
scm>                 used to browse the tree and the various revisions of the
scm>                 files, perform arbitrary diffs, etc?
scm>             </expl>
scm>             <compare>
scm>                 <s id="cvs">Yes. 
scm>                     <a href="http://www.freebsd.org/projects/cvsweb.html">CVSweb</a>,
scm>                     <a href="http://www.viewvc.org/">ViewVC</a>,
scm>                     <a href="http://www.horde.org/chora/">Chora</a>,
scm>                     and <a href="http://wwcvs.republika.pl/">wwCVS</a>.
scm>                 </s>
scm>                 <s id="bazaar">
scm>                     Yes, several:
scm>                     <a href="http://www.lag.net/loggerhead/">Loggerhead</a>,
scm>                     <a href="http://goffredo-baroncelli.homelinux.net/bazaar/">Webserve</a>,
scm>                     <a href="http://mccormick.cx/dev/bzrweb/index.py/log/bzrweb/head">Bzrweb</a>,
scm>                     and
scm>                     <a href="http://bazaar-vcs.org/TracBzr">Trac</a>.
scm>                 </s>
scm>                 <s id="mercurial">Yes.  The web interface is a bundled component.</s>
scm>                 <s id="git">
scm>                     Yes.  Gitweb is included in distribution.
scm>                 </s>
scm>             </compare>
scm>         </section>

For other SCMs there are listed many different web interfaces.
So I would perhaps put here a list:

  Yes.  Gitweb (in Perl) is included in distribution, but there are
  many other web interfaces:
  <a href="http://hjemli.net/git/cgit/">cgit</a> (in C),
  <a href="http://code.google.com/p/git-php/">git-php</a> and
  <a href="http://people.proekspert.ee/peeter/blog/index.php?category=5">its fork<a> (in PHP),
  <a href="http://viewgit.sourceforge.net/">ViewGit</a> (in PHP),
  <a href="http://www.flameeyes.eu/projects#gitarella">Gitarella</a> (in Ruby)

Perhaps we should leave programming language used, as there is no such
information provided for other SCM listed in comparison.

Comments:

I have not put Wit by Daniel Chokola in Ruby/eRuby, as the site seems
to be down. I also didn't add GitStat which is not web interface but
offers instead web-based statistics about repository, and hosting
solutions such as Gitorious (in Ruby), InDefero (in PHP) and GitHub
(not open, in Ruby).

I'm also not sure which one of git-php implementations to list; perhaps
simply the first one, the one that has kind of homepage on Google Code.

scm>         <section id="availability_of_guis">
scm>             <title>Availability of Graphical User-Interfaces.</title>
scm>             <expl>
scm>                 What is the availability of graphical user-interfaces for
scm>                 the system? How many GUI clients are present for it?
scm>             </expl>
scm>             <compare>
scm>                 <s id="bazaar">
scm>                     There are several graphical frontends in
scm>                     development,
scm>                     see <a href="http://bazaar-vcs.org/BzrPlugins">the Bazaar Plugins page</a>
scm>                     and <a href="http://bazaar-vcs.org/3rdPartyTools">the Third-party Tools page</a>.
scm>                     Notable
scm>                     are <a href="http://bazaar-vcs.org/QBzr">QBzr
scm>                     (Qt)</a> and 
scm>                     <a href="http://bazaar-vcs.org/bzr-gtk">bzr-gtk (GTK+)</a>, which
scm>                     can be considered beta quality.  Work is also
scm>                     being done on integrating Bazaar with Windows
scm>                     Explorer, Eclipse, Nautilus, and Meld.
scm>                 </s>
scm>                 <s id="mercurial">
scm>                     History viewing available with hgit extension;
scm>                     check-in extension (hgct) makes committing easier.
scm>                     Some third-party IDEs and GUI tools (e.g. eric3,
scm>                     meld) have integrated Mercurial support.
scm>                 </s>
scm>                 <s id="git">
scm>                     Gitk is included in distribution.  
scm>                     Qgit and Git-gui tools are also available.
scm>                 </s>

Re-wrapped.

scm>            </compare>
scm>         </section>
scm>     </section>

There is a question whether to list all (or at least more popular) GUI
tools, or list only built-in and perhaps one or two more, and direct
to Git Wiki for details, like below:

  Gitk history viewer and Git-gui commit tool are included in distribution.
  There are also other tools available, like
  <a href="http://digilander.libero.it/mcostalba/">QGit</a> (Qt) nad
  <a href="http://github.com/Caged/gitnub/wikis">GitNub</a> (MacOS);
  see <a href="http://git.or.cz/gitwiki/InterfacesFrontendsAndTools#gui">Interfaces,
  Frontends And Tools</a> page on Git Wiki for a list.

I have listed two most popular GUI according to currently open survey
  http://www.survs.com/shareResults?survey=M3PIVU72&rndm=OKJQ45LAG8

Comments:

Should there be mentioned integration and beginning of integration with
IDE, editors and other tools in the form of EGit (Eclipse Git plugin),
similar work for NetBeans and IntelliJ/JetBeans, Git TextMate bundle,
Emacs modes (git.el, vc-git.el, DVC, magit), and support from other
tools like PIDA and Meld?  It is mentioned for other SCM, but it is
not GUI in exact meaning of this word.

scm>     <section id="license">
scm>         <title>License</title>
scm>         <expl>
scm>             What are the licensing terms for the software? 
scm>         </expl>
scm>         <compare>
scm>             <s id="mercurial">GNU GPL (open source)</s>
scm>             <s id="git">GNU GPL v2 (open source).</s>
scm>         </compare>
scm>     </section>
scm> </section>

No comments here.

-- 
Jakub Narebski
Poland