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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
