# Adding Git to Better SCM Initiative : Comparison 11 messages from 2007-11-28 to 2007-12-03. Participants: Jakub Narebski, Robin Rosenberg, Jan Hudec, Alex Riesen, Johan Herland. Thread: https://gitlist.dev/t/11052 ## Jakub Narebski, 2007-11-28 22:39 Subject: Adding Git to Better SCM Initiative : Comparison Message-ID: <200711282339.59938.jnareb@gmail.com> URL: https://gitlist.dev/e/200711282339.59938.jnareb%40gmail.com ``` I'd like to add Git to comparison table of SCMs at Better SCM Initiative site: http://better-scm.berlios.de To do that, I need to fill in infomration about Git. Most of questions / items didn't give much problem, but there are a few on which I would like your input. (Yes, I know that such SCM comparisons are usually biased towards the idea of what are most important features of a version control system. Nevertheless...) 1. Ease of Deployment How easy it is to deploy the software? What are the depenedencies and how can they be satisfied? There are binary packages for Linux (RPM, deb) and for MS Windows (msysGit). Git requires POSIX shell, Perl, and POSIX utilities (BTW. INSTALL file lacks full specification of dependences); although there is ongoing effort towards making all commands builtin, in C. Makefile contains ready configuration for many OS, and there is autoconf script to generate Makefile configuration. I'm not sure if the problems with compiling documentation to HTML and manpage forms, which require AsciiDoc and xmlto toolchains should be also mentioned here. Well, that and the fact that there exist pre-build documentation in html and man forms. 2. Command Set What is the command set? How compatible it is with the commands of CVS (the current open-source defacto standard)? Should it be: "Tries to follow CVS conventions, but deviates where there is a different design.", as for Mercurial and Monotone? If I remember correctly command set is patterned somewhat after BitKeeper. "Large command set divided into plumbing (low lewel, to be used in scripts) and porcelain (high level commands)." 3. Portability How portable is the version-control system to various operating systems, computer architectures, and other types of systems? "Good. Portable across all POSIX systems. There exists Win32 binary using MinGW." >From the results of Git User's Surveys there are many OS on which Git is used; but it doesn't tell us how hard was to deply Git on those exotic operatings systems. 4. Repository Permissions Is it possible to define permissions on access to different parts of a remote repository? Or is access open for all? "Partial (?). It is possible to lock down repository (access to branches and tags) using hooks." I don't know if it is possible to do finer level ACLs, i.e. if it is possible to lock subdirectories or files in Git. Although for distributed SCMs ACL doesn't matter much: check diffstat and merge or not from trusted people. We have "network of trust" (BTW. Karl Fogel in OSSBook recommends 'soft' control of access control to repository, on social rather than on technical level). P.S. How do "svn diff" looks like? -- Jakub Narebski Poland ``` ## Robin Rosenberg, 2007-11-29 01:48 Subject: Re: Adding Git to Better SCM Initiative : Comparison Message-ID: <200711290248.23239.robin.rosenberg.lists@dewire.com> URL: https://gitlist.dev/e/200711290248.23239.robin.rosenberg.lists%40dewire.com In-Reply-To: <200711282339.59938.jnareb@gmail.com> ``` onsdag 28 november 2007 skrev Jakub Narebski: > I'd like to add Git to comparison table of SCMs at Better SCM > Initiative site: > http://better-scm.berlios.de > > To do that, I need to fill in infomration about Git. Most > of questions / items didn't give much problem, but there > are a few on which I would like your input. > > (Yes, I know that such SCM comparisons are usually biased towards the > idea of what are most important features of a version control system. > Nevertheless...) [...] > 4. Repository Permissions > > Is it possible to define permissions on access to different > parts of a remote repository? Or is access open for all? > > "Partial (?). It is possible to lock down repository > (access to branches and tags) using hooks." > > I don't know if it is possible to do finer level ACLs, i.e. if it > is possible to lock subdirectories or files in Git. Although for > distributed SCMs ACL doesn't matter much: check diffstat and merge or > not from trusted people. We have "network of trust" (BTW. Karl Fogel > in OSSBook recommends 'soft' control of access control to repository, > on social rather than on technical level). I think what is most interesting here is access to content for which git has just about nothing worth mentioning, Just admit it. "Truth in advertising". I did start doing this so here's my version (pre-msysgit). Please try to bring up the defintion of "atomic" again with the author. I did complain a little but nothing happened. The issue is that Clearcase is listed as having "atomic" commits which is not true for any usable definition of atomic in SCM context. With the definition in use there I think CVS should be considered having atomic commits too, at least I've never seen a half-committed file there. % svn diff Index: src/comparison/scm-comparison.xml =================================================================== --- src/comparison/scm-comparison.xml (revision 290) +++ src/comparison/scm-comparison.xml (arbetskopia) @@ -71,6 +71,9 @@ LibreSource Synchronizer + + Git + $Id$ @@ -182,6 +185,13 @@ needs to be up-to-date before doing a rename/move operation. This operation will be committed directly. + + Yes (or no depending on interpretation). Git typically detects + renames and copies based on content regardless of whether the + committer indicated the fact. The detection is content based + rather than file-id based. There is explicit rename too, but + it is not used much. +
@@ -236,6 +246,10 @@ limitations in Windows environments) No, copies will start there own history. + Yes(or no depending on interpretation). Git detects + copies and moves based on content. It does not track + history on a file-id based scheme. +
@@ -288,6 +302,11 @@ Yes, but is not documented and its based on the dataflow feature of the LibreSource Synchronizer. + + Yes. This is a fundamental part of using Git. A Git user typically always + has a full copy of the entire repostory (well compressed) that is initialized + using a clone command. +
@@ -331,6 +350,7 @@ Yes, as long as you have the (more expensive) Distributed package. Yes, using Clearcase Multisite. Yes, it's what we call a dataflow. + Yes. This is a fundamental part of using Git.
@@ -417,7 +437,8 @@ multi-platform environments. Permissions are set for the whole repository or branch. - + No, but bad changes can be reverted before they are published. +
Changesets' Support @@ -490,6 +511,11 @@ Partial support. There are implicit changeset that are generated on each commit. + Yes. Actually Git is snapshot based which means Git records + the full state in every commit, which means that any two + commits can be compared directly very quickly, although the + repository is typically browsed as a series of change sets. +
@@ -534,6 +560,9 @@ Yes locally without any server connection with the standard graphical Java client. + Yes. It can also detect the origin of copied and moved source + lines. +
@@ -610,6 +639,12 @@ It is possible to commit only a certain directory. However, one must check out the entire repository as a whole. + No. However it is possible to commit only selected + changes in the working tree rather than everything. Subproject + support makes it possible to split large projects into several + repositories and link them. Related repositories need not be + checked out or cloned. +
@@ -659,6 +694,10 @@ Yes, with the Synchronizer Studio (default Java client) or with the standard diff command (diff -r . .so6/xxx/REFCOPY/) + Yes. In addition commits are local and will not be seen + until he/she decides to publish them making it possible to + track multiple versions locally before publishing. +
@@ -714,6 +753,7 @@ for a per-changeset message. No. Commit messages are per changeset. + No. The same message applies the the commit as a whole.
@@ -828,6 +868,11 @@ documentation. Installing and getting started with the GUI is very easy though. (update/commit-next-next-next-finished) + + There a good tutorials manual pages and a supportive community. + Basic usage is simple, but advanced usage requires understanding of + what makes git different. +
@@ -950,6 +995,10 @@ LibreSource repository web page. (links: create workspace, update, commit, studio...) + + Very simple to deploy on Unix-like systems. Windows installs + is not fully developed yet. Installing in cygwin is simple though. +
@@ -1048,6 +1097,13 @@ Basic commands available (commit/update), but it's really simple to use the GUI. Ant task are also available. + Basic usage could be considered similar, but trying + to use Git like CVS would be counterproductive since many + cases of CVS usage is by design not possible in Git. The + number of command is large. ~140 but only ~20 commands + are typically used and less than ten will do for casual + users. +
@@ -1152,6 +1208,13 @@ Good. Use of HTTP to get through firwalls. + + Excellent. Normal usage is off-line, but networking is + used for sharing changes Networking including ssh, + a special git protocol http and mail can be used to share + changes, both incoming and outgoing. Mail can be used + via IMAP and mbox files. +
@@ -1249,6 +1312,11 @@ Excellent. Clients and servers work on any Java 1.5-compatible platform. (Windows, Linux and Mac OS X ) + + Very good for POSIX compatible environments. A non-cygwin + port for windows is underway. There are some graphical + tools available for windows in cygwin. +
@@ -1323,6 +1391,7 @@ Yes, without diff features but with a better awareness support. (allow to know at any time on each version each one is working on) + Yes. gitweb
@@ -1421,6 +1490,10 @@ is automatically launched from the repository web page and another one which is an Eclipse plugin. + + A number of good GUI's are availble for basic usage, + but typical usage is command based. +
@@ -1501,7 +1574,8 @@ additional licensing. QPL - The Qt Public License (OpenSource) - + GPL + -- robin ``` ## Jakub Narebski, 2007-11-29 02:26 Subject: Re: Adding Git to Better SCM Initiative : Comparison Message-ID: <200711290326.13822.jnareb@gmail.com> URL: https://gitlist.dev/e/200711290326.13822.jnareb%40gmail.com In-Reply-To: <200711282339.59938.jnareb@gmail.com> ``` Jakub Narebski wrote: > To do that, I need to fill in information about Git.  Most > of questions / items didn't give much problem, but there > are a few on which I would like your input. By the way, below is patch with the information I have filled. Check out the TO DO items. diff --git a/src/comparison/scm-comparison.xml b/src/comparison/scm-comparison.xml index b459747..6f84190 100644 --- a/src/comparison/scm-comparison.xml +++ b/src/comparison/scm-comparison.xml @@ -38,6 +38,9 @@ TODO: Darcs + + Git + Mercurial @@ -106,6 +109,7 @@ TODO: Commits are atomic. Commits are atomic. Yes (but need to verify) + Yes. Yes. Yes. Yes. Commits are atomic. @@ -142,6 +146,11 @@ TODO: Yes. Renames are supported. Yes. Renames are supported. Yes. Renames are supported. + + N/A. Git does not track renames, but detects renames + and copies. You can follow history of file using + 'git log --follow'. + Yes. Renames are supported. Yes. Renames are supported. Yes. Renames are supported @@ -214,6 +223,11 @@ TODO: Yes. Copies are supported. No. Copies are not supported. + + N/A. Git does not track copies, but detects renames + and copies. You can follow history of file using + 'git log -C --follow'. + Yes. Copies are supported Yes. Copies are supported No. Copies are not supported. @@ -267,6 +281,7 @@ TODO: Yes. Yes. Yes. + Yes. Yes. Yes. No. @@ -313,6 +328,7 @@ TODO: Yes. Yes. Yes. + Yes. Yes. Yes. No. @@ -373,6 +389,10 @@ TODO: Same as subversion. + + Partial (?). It is possible to lock down repository + (access to branches and tags) using hooks. + Yes. It is possible to lock down repositories, subdirectories, or files using hooks. @@ -455,6 +475,9 @@ TODO: Yes. Changesets are supported. + + Yes. Changesets are supported. + Yes. Changesets are supported. @@ -509,6 +532,7 @@ TODO: Not in the command line client, but ViewARCH, a web-interface for Arch, has it. Yes. (darcs annotate) + Yes. (git blame, git gui blame) Yes. (hg annotate) Yes, as of version 0.19. Yes. aeannotate @@ -570,6 +594,9 @@ TODO: whole. No. All changes are made repository-wide. + + No. All changes are made repository-wide. + But you can use submodules / subrpoject support for that. It is possible to commit changes only in a subset of the tree. There are plans for partial checkouts. @@ -636,6 +663,10 @@ TODO: Yes, using "darcs whatsnew". Yes. Using aediff + + Yes. Using git diff. + Note that git uses staging area for commits (index). + Yes. Using hg diff. Yes. In a similar fashion to CVS. Yes. Using cm diff @@ -681,6 +712,10 @@ TODO: No. + + No. But you can tag (with description) given contents + of a file (blob). + No. @@ -782,6 +817,15 @@ TODO: and the client contains a help tool that offers an integrated help system. + + Medium. There's Git User's Manual, manpages, some + technical documentation and some howtos. All + documentation is also available online in HTML format; + there is additional information (including beginnings + of FAQ) on git wiki. + Nevertheles one of complaints in surveys is insufficient + or fragmented documentation. + Very good. There's an overview and tutorial on the web site, and integrated help for every command. @@ -894,6 +938,14 @@ TODO: to install the subversion perl bindings and a few modules from CPAN. + + TO DO. RPMs and deb packages for Linux. msysGit and + Cygwin for Win32 - Git requires POSIX shell, Perl, + and POSIX utilities for some commands (builtin). + Autoconf to generate Makefile configuration; ready + generic configuration for many OS. Compiling docs + requires asciidoc and xmlto toolchain, but prebuild. + Excellent. Binary packages are available for all popular platforms. Building from source requires @@ -1006,6 +1058,13 @@ TODO: but since the model is different most commands are unique. + + TO DO. + Tries to follow CVS conventions, but deviates where there + is a different design. + Large command set divided into plumbing (low lewel, to be + used in scripts) and porcelain (high level). + Tries to follow CVS conventions, but deviates where there is a different design. @@ -1106,6 +1165,10 @@ TODO: There exists some HTTP-functionality, but it is quite limited. + + Good. Uses HTTPS (with WebDAV) or ssh for push, + HTTP, FTP, ssh or custom protocol for fetch. + Excellent. Uses HTTP or ssh. Remote access also works safely without locks over read-only network @@ -1203,6 +1266,10 @@ TODO: Very good. Supports many UNIXes, Mac OS X, and Windows, and is written in a portable language. + TO DO. + Good. Portable across all POSIX systems. + There exists Win32 binary using MinGW. + Excellent. Runs on all platforms supported by Python. Repositories are portable across CPU @@ -1300,6 +1367,9 @@ TODO: is included in the distribution. Yes. + + Yes. The web interface is a bundled component. + Other web interfaces: cgit, wit, git-php Yes. The web interface is a bundled component. No. No. @@ -1373,6 +1443,11 @@ TODO: There is tkaegis. + RO DO + Bundled history viewer gitk and commit tool git-gui, + both use Tcl/Tk. There is also qgit (Qt) and Giggle + (GTK+). + History viewing available with hgit extension; check-in extension (hgct) makes committing easier. @@ -1453,6 +1528,7 @@ TODO: GNU GPL (open-source) Perl License. (open source) + GNU GPL (open source) GNU GPL (open source) GNU GPL (open source) -- Jakub Narebski Poland ``` ## Jan Hudec, 2007-11-29 07:17 Subject: Re: Adding Git to Better SCM Initiative : Comparison Message-ID: <20071129071705.GB24070@efreet.light.src> URL: https://gitlist.dev/e/20071129071705.GB24070%40efreet.light.src In-Reply-To: <200711290248.23239.robin.rosenberg.lists@dewire.com> ``` On Thu, Nov 29, 2007 at 02:48:22 +0100, Robin Rosenberg wrote: > I did start doing this so here's my version (pre-msysgit). Please try to bring up the defintion > of "atomic" again with the author. I did complain a little but nothing happened. The issue is > that Clearcase is listed as having "atomic" commits which is not true for any usable definition > of atomic in SCM context. With the definition in use there I think CVS should be considered > having atomic commits too, at least I've never seen a half-committed file there. Actually, I did. Or rather, I did see a commit, that didn't make it to the server, but the client thought it did! Maybe instead of asking the author to change the definition of atomic, ask him to add an item for whole-tree commits. That more precisely describes what is the point. -- Jan 'Bulb' Hudec ``` ## Alex Riesen, 2007-11-29 20:07 Subject: Re: Adding Git to Better SCM Initiative : Comparison Message-ID: <20071129200710.GA3314@steel.home> URL: https://gitlist.dev/e/20071129200710.GA3314%40steel.home In-Reply-To: <200711290326.13822.jnareb@gmail.com> ``` Jakub Narebski, Thu, Nov 29, 2007 03:26:12 +0100: > + > + Medium. There's Git User's Manual, manpages, some > + technical documentation and some howtos. All > + documentation is also available online in HTML format; > + there is additional information (including beginnings > + of FAQ) on git wiki. > + Nevertheles one of complaints in surveys is insufficient "Nevertheless" (two "s"). BTW, I wouldn't call the level of documentation "Medium" when compared to any commercial SCM. How can they earn more than "a little", when compared to any opensource program? > @@ -894,6 +938,14 @@ TODO: > to install the subversion perl bindings and a few modules > from CPAN. > > + > + TO DO. RPMs and deb packages for Linux. msysGit and > + Cygwin for Win32 - Git requires POSIX shell, Perl, > + and POSIX utilities for some commands (builtin). I read this as: "Git requires all these programs for builtin commands". Which is a bit confusing. Just drop "(builtin)"? > + Autoconf to generate Makefile configuration; ready > + generic configuration for many OS. Compiling docs > + requires asciidoc and xmlto toolchain, but prebuild. "prebuilt" (with "t"). Maybe remove ", but prebuilt" completely? > @@ -1106,6 +1165,10 @@ TODO: > There exists some HTTP-functionality, but it is quite > limited. > > + > + Good. Uses HTTPS (with WebDAV) or ssh for push, > + HTTP, FTP, ssh or custom protocol for fetch. > + You forgot bundles (aka SneakerNet). Again, compared to everyone else it is "vastly superior" :) > > Excellent. Uses HTTP or ssh. Remote access also > works safely without locks over read-only network > @@ -1203,6 +1266,10 @@ TODO: > Very good. Supports many UNIXes, Mac OS X, and Windows, > and is written in a portable language. > > + TO DO. > + Good. Portable across all POSIX systems. > + There exists Win32 binary using MinGW. > + "binaries": MinGW and Cygwin. And it is definitely "excellent" by the standards of the site. ``` ## Jakub Narebski, 2007-11-30 00:18 Subject: Re: Adding Git to Better SCM Initiative : Comparison Message-ID: <200711300118.28145.jnareb@gmail.com> URL: https://gitlist.dev/e/200711300118.28145.jnareb%40gmail.com In-Reply-To: <20071129200710.GA3314@steel.home> ``` On Thu, 29 Nov 2007, Alex Riesen wrote: > Jakub Narebski, Thu, Nov 29, 2007 03:26:12 +0100: >> + >> + Medium. There's Git User's Manual, manpages, some >> + technical documentation and some howtos. All >> + documentation is also available online in HTML format; >> + there is additional information (including beginnings >> + of FAQ) on git wiki. >> + Nevertheles one of complaints in surveys is insufficient > > "Nevertheless" (two "s"). > > BTW, I wouldn't call the level of documentation "Medium" when compared > to any commercial SCM. How can they earn more than "a little", when > compared to any opensource program? Source code is not [user level] documentation. But perhaps it should be "Good" instead of "Medium", although I think not "Excellent". >> @@ -894,6 +938,14 @@ TODO: >> to install the subversion perl bindings and a few modules >> from CPAN. >> >> + >> + TO DO. RPMs and deb packages for Linux. msysGit and >> + Cygwin for Win32 - Git requires POSIX shell, Perl, >> + and POSIX utilities for some commands (builtin). > > I read this as: "Git requires all these programs for builtin > commands". Which is a bit confusing. Just drop "(builtin)"? What I meant to say that some Git commands are scripts in Perl or POSIX shell, and that those Git commands requires POSIX utilities (which of those utilities are needed is unfortunately not mentioned explicitely in the INSTALL file); _but_ that there is ongoing effort to rewrite matured commands in C (as built-ins). But this is perhaps too long explanation to put it in this comparison table. >> + Autoconf to generate Makefile configuration; ready >> + generic configuration for many OS. Compiling docs >> + requires asciidoc and xmlto toolchain, but prebuild. > > "prebuilt" (with "t"). Maybe remove ", but prebuilt" completely? Gaaah, it should be "but you can get prebuilt docs". >> @@ -1106,6 +1165,10 @@ TODO: >> There exists some HTTP-functionality, but it is quite >> limited. >> >> + >> + Good. Uses HTTPS (with WebDAV) or ssh for push, >> + HTTP, FTP, ssh or custom protocol for fetch. >> + > > You forgot bundles (aka SneakerNet). > Again, compared to everyone else it is "vastly superior" :) Bundles and patches (peer review!) I think truly move it from "Good" to "Excellent". >> >> Excellent. Uses HTTP or ssh. Remote access also >> works safely without locks over read-only network By the way, can Git be used with repository on lockless network filesystem? (Although with distributed SCM it perhaps be better to just use many distributed repositories...). How does it work with repository available via SMBFS / CIFS or NFS? >> @@ -1203,6 +1266,10 @@ TODO: >> Very good. Supports many UNIXes, Mac OS X, and Windows, >> and is written in a portable language. >> >> + TO DO. >> + Good. Portable across all POSIX systems. >> + There exists Win32 binary using MinGW. >> + > > "binaries": MinGW and Cygwin. And it is definitely "excellent" by the > standards of the site. I'd say excellent on POSIX systems, good on Win32 (there are still as far as I remember some troubles). I hope that gitbox project would succeed, and one would need only single binary (plus perhaps wish for GUI, and DLLs) to use git on MS Windows. -- Jakub Narebski Poland ``` ## Johan Herland, 2007-11-30 01:26 Subject: Re: Adding Git to Better SCM Initiative : Comparison Message-ID: <200711300226.54338.johan@herland.net> URL: https://gitlist.dev/e/200711300226.54338.johan%40herland.net In-Reply-To: <200711300118.28145.jnareb@gmail.com> ``` On Friday 30 November 2007, Jakub Narebski wrote: > On Thu, 29 Nov 2007, Alex Riesen wrote: > > Jakub Narebski, Thu, Nov 29, 2007 03:26:12 +0100: > > >> + > >> + Medium. There's Git User's Manual, manpages, some > >> + technical documentation and some howtos. All > >> + documentation is also available online in HTML format; > >> + there is additional information (including beginnings > >> + of FAQ) on git wiki. > >> + Nevertheles one of complaints in surveys is insufficient > > > > "Nevertheless" (two "s"). > > > > BTW, I wouldn't call the level of documentation "Medium" when compared > > to any commercial SCM. How can they earn more than "a little", when > > compared to any opensource program? > > Source code is not [user level] documentation. > > But perhaps it should be "Good" instead of "Medium", although I think > not "Excellent". If we try to compare ourselves to what's closest, i.e. Mercurial, I would say that Git's documentation is probably on par with what Mercurial has to offer. Their "Documentation" entry in the comparison is as follows: "Very good. There's an overview and tutorial on the web site, and integrated help for every command." I say we go for something similar. Have fun! ...Johan -- Johan Herland, www.herland.net ``` ## Jakub Narebski, 2007-11-30 01:53 Subject: Re: Adding Git to Better SCM Initiative : Comparison Message-ID: <200711300253.55759.jnareb@gmail.com> URL: https://gitlist.dev/e/200711300253.55759.jnareb%40gmail.com In-Reply-To: <200711300226.54338.johan@herland.net> ``` On Fri, 30 Nov 2007, Johan Herland wrote: > On Friday 30 November 2007, Jakub Narebski wrote: >> On Thu, 29 Nov 2007, Alex Riesen wrote: >>> Jakub Narebski, Thu, Nov 29, 2007 03:26:12 +0100: >> >>>> + >>>> + Medium. There's Git User's Manual, manpages, some >>>> + technical documentation and some howtos. All >>>> + documentation is also available online in HTML format; >>>> + there is additional information (including beginnings >>>> + of FAQ) on git wiki. >>>> + Nevertheles one of complaints in surveys is insufficient >>> >>> "Nevertheless" (two "s"). >>> >>> BTW, I wouldn't call the level of documentation "Medium" when compared >>> to any commercial SCM. How can they earn more than "a little", when >>> compared to any opensource program? >> >> Source code is not [user level] documentation. >> >> But perhaps it should be "Good" instead of "Medium", although I think >> not "Excellent". > > If we try to compare ourselves to what's closest, i.e. Mercurial, I would > say that Git's documentation is probably on par with what Mercurial has to > offer. Their "Documentation" entry in the comparison is as follows: > > "Very good. There's an overview and tutorial on the web site, and integrated > help for every command." > > I say we go for something similar. Well, at least according to surveys results people perceive "The Mercurial Book" (hgbook) as better documentation than "Git User's Manual" + tutorials. See for example frequent requests for "The Git Book" patterned after hgbook and/or svnbook. BTW. the list was meant to be updated by contributors who added SCMs, but it doesn't liik lik it is... -- Jakub Narebski Poland ``` ## Alex Riesen, 2007-11-30 07:16 Subject: Re: Adding Git to Better SCM Initiative : Comparison Message-ID: <20071130071634.GA2975@steel.home> URL: https://gitlist.dev/e/20071130071634.GA2975%40steel.home In-Reply-To: <200711300118.28145.jnareb@gmail.com> ``` Jakub Narebski, Fri, Nov 30, 2007 01:18:27 +0100: > >> > >> Excellent. Uses HTTP or ssh. Remote access also > >> works safely without locks over read-only network > > By the way, can Git be used with repository on lockless network > filesystem? (Although with distributed SCM it perhaps be better > to just use many distributed repositories...). How does it work > with repository available via SMBFS / CIFS or NFS? Works fine. CIFS/SMBFS is slow as hell when hosted on windows, but I figure it is not problem of Git. ``` ## Jan Hudec, 2007-11-30 18:34 Subject: Re: Adding Git to Better SCM Initiative : Comparison Message-ID: <20071130183414.GD30048@efreet.light.src> URL: https://gitlist.dev/e/20071130183414.GD30048%40efreet.light.src In-Reply-To: <20071129200710.GA3314@steel.home> ``` On Thu, Nov 29, 2007 at 21:07:10 +0100, Alex Riesen wrote: > Jakub Narebski, Thu, Nov 29, 2007 03:26:12 +0100: > > + > > + Medium. There's Git User's Manual, manpages, some > > + technical documentation and some howtos. All > > + documentation is also available online in HTML format; > > + there is additional information (including beginnings > > + of FAQ) on git wiki. > > + Nevertheles one of complaints in surveys is insufficient > > "Nevertheless" (two "s"). I think it's not amount of documentation that's insufficient, but rather the organization. The problem is not that the information is not there, but that it's sometimes not easy to find. > BTW, I wouldn't call the level of documentation "Medium" when compared > to any commercial SCM. How can they earn more than "a little", when > compared to any opensource program? I don't know that many commercial SCM, but clearcase does have more than "a little" documentation. > [...] > > > @@ -1106,6 +1165,10 @@ TODO: > > There exists some HTTP-functionality, but it is quite > > limited. > > > > + > > + Good. Uses HTTPS (with WebDAV) or ssh for push, > > + HTTP, FTP, ssh or custom protocol for fetch. > > + > > You forgot bundles (aka SneakerNet). > Again, compared to everyone else it is "vastly superior" :) In fact at least darcs and bzr can also do SneakerNet. -- Jan 'Bulb' Hudec ``` ## Jakub Narebski, 2007-12-03 19:57 Subject: Adding Git to Better SCM Initiative : Comparison Message-ID: <200712032057.15296.jnareb@gmail.com> URL: https://gitlist.dev/e/200712032057.15296.jnareb%40gmail.com In-Reply-To: <200711282339.59938.jnareb@gmail.com> ``` Below there is email I want to send to Shlomi Fish to have him include GIT in "Better SCM Initiative : Comparison page". Please check it and send comments and corrections. TIA. -- >8 -- I have noticed that your SCM comparison at "Better SCM Initiative" website http://better-scm.berlios.de/comparison/comparison.html misses GIT, version control system which is used to manage Linux kernel. GIT was created by Linus Torvalds in response to the change of BitKeeper licensing, as a tool to manage Linux kernel sources. It is based on three years of Linus experience with BitKeeper, and inspired by Monotone architecture. It was designed for Linux kernel, and is used by various projects, including X.Org, various Freedesktop projects, WINE, OLPC (One Laptop Per Child), Samba. Git is a popular version control system designed to handle very large projects with speed and efficiency; it is used mainly for various open source projects, most notably the Linux kernel. Git falls in the category of distributed source code management tools, similar to e.g. GNU Arch or Monotone (or BitKeeper in the proprietary world). Every Git working directory is a full-fledged repository with full revision tracking capabilities, not dependent on network access or a central server. Git is an Open Source project covered by the GNU General Public License v2. It was originally written by Linus Torvalds and is currently maintained by Junio C Hamano. Below there is patch to the sources for the site. BTW. when asking about updating GIT info for comparison, please CC git mailing list, git@vger.kernel.org Index: src/comparison/scm-comparison.xml =================================================================== --- src/comparison/scm-comparison.xml (revision 290) +++ src/comparison/scm-comparison.xml (working copy) @@ -38,6 +38,9 @@ Darcs + + Git + Mercurial @@ -106,6 +109,7 @@ Atomic Commits Commits are atomic. Commits are atomic. Yes (but need to verify) + Yes. Yes. Yes. Yes. Commits are atomic. @@ -142,6 +146,13 @@ Files and Directories Moves or Renames Yes. Renames are supported. Yes. Renames are supported. Yes. Renames are supported. + + Yes (or no depending on interpretation). Git detects + renames based on content regardless of whether the + committer indicated the fact. + You can follow history of file across renames using + 'git log -M --follow'. + Yes. Renames are supported. Yes. Renames are supported. Yes. Renames are supported @@ -214,6 +225,13 @@ File and Directories Copies Yes. Copies are supported. No. Copies are not supported. + + Yes (or no depending on interpretation). Git detects + copies (when requested) based on content regardless + of whether the committer indicated the fact. + You can follow history of file across copies using + 'git log -C -C --follow'. + Yes. Copies are supported Yes. Copies are supported No. Copies are not supported. @@ -267,6 +285,7 @@ Remote Repository Replication Yes. Yes. Yes. + Yes. Yes. Yes. No. @@ -313,6 +332,7 @@ Propagating Changes to Parent Repositories Yes. Yes. Yes. + Yes. Yes. Yes. No. @@ -373,6 +393,10 @@ Repository Permissions Same as subversion. + + Partial (?). It is possible to lock down repository + (access to branches and tags) using hooks. + Yes. It is possible to lock down repositories, subdirectories, or files using hooks. @@ -455,6 +479,13 @@ Changesets' Support Yes. Changesets are supported. + + Yes. Changesets are supported.
+ Actually Git is snapshot based which means Git records + the full state in every commit. This means that any two + commits can be compared directly very quickly, although the + repository is typically browsed as a series of changesets. + Yes. Changesets are supported. @@ -509,6 +540,11 @@ Tracking Line-wise File History Not in the command line client, but ViewARCH, a web-interface for Arch, has it. Yes. (darcs annotate) + + Yes. (git blame, git gui blame). + It can also detect the origin of copied and moved source + lines, and can ignore whitespace changes. + Yes. (hg annotate) Yes, as of version 0.19. Yes. aeannotate @@ -570,6 +606,11 @@ Ability to Work only on One Directory... whole. No. All changes are made repository-wide. + + No. All changes are made repository-wide. However + it is possible to commit only selected changes in the + working tree rather than everything. You can also + use submodules (subproject) support. It is possible to commit changes only in a subset of the tree. There are plans for partial checkouts. @@ -636,6 +677,10 @@ Tracking Uncommited Changes Yes, using "darcs whatsnew". Yes. Using aediff + + Yes, of course. Using git diff. + Note that git uses staging area for commits (index). + Yes. Using hg diff. Yes. In a similar fashion to CVS. Yes. Using cm diff @@ -681,6 +726,11 @@ Per-File Commit Messages No. + + No. The message applies to the commit as a whole. + But you can tag (with description) given contents + of a file (blob). + No. @@ -782,6 +832,15 @@ Documentation and the client contains a help tool that offers an integrated help system. + + Good. There's Git User's Manual, manpages, some + technical documentation and some howtos. All + documentation is also available + online + in HTML format; there is additional information (including + beginnings of FAQ) on a + git wiki. + Very good. There's an overview and tutorial on the web site, and integrated help for every command. @@ -894,6 +953,16 @@ Ease of Deployment to install the subversion perl bindings and a few modules from CPAN. + + Very good. Install from RPM or deb on Linux; use + msysGit or Cygwin install on Windows. Git requires + zlib; also POSIX shell and utilities and Perl for some + commands. + Installing from sources is easy: Makefile has ready + configuration for many OS, you can also use autoconf + to generate Makefile configuration. Compiling docs + requires asciidoc toolchain, but you can use prebuild. + Excellent. Binary packages are available for all popular platforms. Building from source requires @@ -1006,6 +1075,13 @@ Command Set but since the model is different most commands are unique. + + Tries to follow CVS conventions, but deviates where there + is a different design (following BitKeeper for DVCS). + Large command set (~140) is divided into plumbing commands + (low lewel, to be used in scripts) and porcelain (high level). + It is easy to add new commands as scripts, or as git aliases. + Tries to follow CVS conventions, but deviates where there is a different design. @@ -1106,6 +1182,13 @@ Networking Support There exists some HTTP-functionality, but it is quite limited. + + Excellent. Uses HTTPS (with WebDAV) or ssh for push + (to publish changes to server) and HTTP, FTP, ssh or custom + "git" protocol for fetch (read from server). There is also + git-bundle for offline transport, and tools to exchange + (create and apply) patches via email. + Excellent. Uses HTTP or ssh. Remote access also works safely without locks over read-only network @@ -1203,6 +1286,11 @@ Portability Very good. Supports many UNIXes, Mac OS X, and Windows, and is written in a portable language. + + Good to very good. Portable across all POSIX systems. + There exists Win32 binary using MinGW (msysGit), + or you can use binary provided by Cygwin. + Excellent. Runs on all platforms supported by Python. Repositories are portable across CPU @@ -1300,6 +1388,10 @@ Web Interface is included in the distribution. Yes. + + Yes, gitweb is included in git since version 1.4.0. + Other web interfaces exists: cgit, wit, git-php + Yes. The web interface is a bundled component. No. No. @@ -1373,6 +1464,12 @@ Availability of Graphical User-Interfaces. There is tkaegis. + + There is history viewer 'gitk' and commit tool 'git-gui'; + both in Tcl/Tk. There also exists a number of third-party + GUIs, including: qgit (Qt), GitView (GTK+), Giggle (GTK+), + tig (ncurses). + History viewing available with hgit extension; check-in extension (hgct) makes committing easier. @@ -1453,6 +1550,7 @@ License GNU GPL (open-source) Perl License. (open source) + GNU GPL v2 (open source) GNU GPL (open source) GNU GPL (open source) ```