{"thread":{"id":"15518","subject":"Git at Better SCM Initiative comparison of VCS (long)","startedAt":"2008-09-13T17:06:16Z","lastAt":"2008-10-01T18:45:13Z","messageCount":9,"participants":["Jakub Narebski","Dmitry Potapov","Alexey Mahotkin","Shawn O. Pearce"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"90640","messageId":"200809131906.18746.jnareb@gmail.com","threadId":"15518","inReplyTo":null,"subject":"Git at Better SCM Initiative comparison of VCS (long)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-09-13T17:06:16Z","receivedAt":"2008-09-13T17:06:16Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"I have tried a few times to add information about Git to comparison\ntable of SCMs at 'Better SCM Initiative' (http://better-scm.berlios.de)\n\n  http://thread.gmane.org/gmane.comp.version-control.git/66445\n  http://thread.gmane.org/gmane.comp.version-control.git/67708\n\nbut somehow I didn't lead it to conclusion, namely adding Git to\nthe comparison table.  (Sidenote: Data from 'Better SCM : Comparison'\nis used also for versioncontrolblog \"Version control systems comparison\"\nat http://versioncontrolblog.com/comparison).\n\nI have thought about trying yet another time... but Git was already\nadded; see http://better-scm.berlios.de/news/changes-2008-08-07/\nNow I have checked information about Git and think that this table\nneeds a few corrections and, in some places, extra explanation.\n\n\nLet us here come together with a version we can be happy with, which\nI would be then able to send as correction for Better SCM Initiative\ncomparison (http://better-scm.berlios.de/contribute/).\n\nBelow there are excerpts from source of comparison table (from SVN)\n\n  http://opensvn.csie.org/betterscm/better-scm-site/trunk/src/comparison/scm-comparison.xml\n\nmarked as quoted text (with 'scm>'), optionally un-indented and\nre-wrapped for better readibility. My comments follow as if they\nwere replies to an email.\n\n---\nscm> <?xml version='1.0' encoding='utf-8'?>\nscm> <?xml-stylesheet type=\"text/xml\" href=\"compare-ml.xsl\"?>\nscm> <!DOCTYPE comparison SYSTEM \"comparison.dtd\">\nscm> <!--\nscm> TODO:\nscm> \nscm> * Add intelligent merging of renamed paths.\n\nThe comparison has a new criterion: \"Intelligent Merging after Moves\nor Renames\" since 2008-08-07, so the first item in this TODO list\nshould have been removed, I think.\n\nscm> * Add IDE integration.\nscm> * Integration with build/testing management.\nscm> * Check-In policies.\nscm> * Add Speed (?)\nscm> -->\n\nThe problem of course with adding new criterion is that it should be\nadded for _all_ (currently 27) version control systems (SCMs) covered.\n\nscm> <comparison>\nscm>     <meta>\nscm>         <implementations>\n\nscm>             <impl id=\"git\">\nscm>                 <name>Git</name>\nscm>                 <url>http://git.or.cz/</url>\nscm>             </impl>\n\nHmmm... what to do about the fact that currently Git has _two_ forks of\na homepage: http://git.or.cz (aka http://git-scm.org) by Petr 'Pasky'\nBaudis and new http://git-scm.com by Scott Chacon, I do wonder...\n\nBut those are just aimless musings... the above is O.K.\n\nscm>         </implementations>\nscm>         <timestamp>\nscm>             $Id: scm-comparison.xml 322 2008-08-09 05:47:26Z shlomif $\nscm>         </timestamp>\nscm>     </meta>\nscm>     <contents>\nscm> <section id=\"main\">\nscm>     <title>Version Control System Comparison</title>\nscm>     <expl>\nscm>         This is a comparison of version-control systems. It is split\nscm>         into several categories and sub-categories under which the \nscm>         systems are checked.\nscm>     </expl>\nscm>     <section id=\"repos_operations\">\nscm>         <title>Repository Operations</title>\nscm>         <section id=\"atomic_commits\">\nscm>             <title>Atomic Commits</title>\nscm>             <expl>\nscm>                 Support for atomic commits means that if an\nscm>                 operation on the repository is interrupted\nscm>                 in the middle, the repository will not be\nscm>                 left in an inconsistent state. Are the\nscm>                 check-in operations atomic, or can\nscm>                 interrupting an operation leave the\nscm>                 repository in an intermediate state?\nscm>             </expl>\n\nHere I think the explanation of a criterion (feature) is clear enough.\nI might have added that \"interruption\" include killing of a process\nduring for example commit, lack of disk space for a full commit, or\na network fail during network operation (fetch or push, or equivalent).\n\nscm>             <compare>\nscm>                 <s id=\"git\">Yes. Commits are atomic.</s>\nscm>             </compare>\n\nO.K.\n\nscm>         </section>\nscm>         <section id=\"move\">\nscm>             <title>Files and Directories Moves or Renames</title>\nscm>             <expl>\nscm>                 Does the system support moving a file or directory to\nscm>                 a different location while still retaining the history\nscm>                 of the file? <b>Note:</b> also see the next section\nscm>                 about intelligent merging of renamed paths.\nscm>             </expl>\n\nIn my opinion this criterion is next to worthess without more in depth\nclarification of what does it mean to \"support\" moves or renames; as\nentries for different systems are written by different people, if it\nis not clear how to check if some feature is supported, some might\nwrite 'no' for some system A, and some other person can write 'yes'\nfor other system B, even if the support is better in system A than in\nsystem B (and would be considered enough, i.e. 'yes' answer, by the\ncreator of this criterion).\n\nFor me the support for renames/moves and copying (see next section)\nmeans that:\n\n 0.) When examining or going to some point in the history (some old\n     revision/version of a project) the state you get is _exactly_\n     the same as it was at that time, exactly the same as it was\n     recorded (comitted) then.\n\n     For example tricks with moving *,v files in the CVS repository\n     break this assertion.\n\n 1.) When examining history of a project as a whole version control\n     system tells you that file was renamed (moved). I would consider\n     having there renaming represented as copy + delete to be only\n     a partial support of this feature.\n\n     Note that while tool might correctly notify about file renames\n     (I would consider heuristics which give correct answer in 99%\n     or so \"true life\" example to 'correctly notify'), it might notice\n     full directory renames only as renames of individual files.\n     I guess that at least for some systems this issue was not taken\n     into account...\n\n 2.) When examining history of an individual file (or perhaps even of\n     an individual directory), either in the form of list of revisions\n     which touch given file in the form of \"$scm log <file>\" output or\n     some graphical history viewer output, or in the form of annotations\n     of file contents (so called here 'per-line history') in the form\n     of \"$scm blame <file>\" / \"$scm annotate <file>\", we would want for\n     SCM to follow history of contents across file renames (and other\n     code movements if possible; but that is outside of scope of this\n     criterion).\n\n     Side note: history of two files can be more than sum (union) of\n     histories of individual files.\n     \nFrom the comments I have heard it looks like at least for some version\ncontrol systems contributors used the meaning '0', while most users\n(readers) would think of '1+2', good if not forgetting about '0'.\n\nHere (and in other places) it would be nice to have actual *TEST*, which\ncan be used to determine if given version control system \"supports\"\n'Files and Directories Moves or Renames' criterion/feature. Attention!\nbecause Git does similarity based rename detection (contents + pathname\nbased similarity score), one should use better some larger test vector,\notherwise Git and other systems using rename detection would be at\ndisadvantage. An example of such test would be t/t*rename* tests from\ngit; we could also use 'Lorem ipsum' or 'Dominus regit me' test vectors.\n\nSo for example 1.) could be tested as:\n $ scm add A\n $ ...\n $ scm mv A B\n $ ...\n $ scm log [options]   # <- has info about A => B rename\n\nwhile 2.) could be tested as:\n $ scm add A\n $ ...\n $ scm mv A B\n $ ...\n $ scm log [options] B  # <- goes to initial revision of A\n\n\nBy the way, there is even simpler operation than support for renames\nthat SCM can screw up (file-history based SCM are specially\nsusceptible).  Try to delete a file, and then later create _different_\nfile (separate history) with the same filename.\n\nscm>             <compare>\n\nscm>                 <s id=\"git\">\nscm>                     Renames are supported for most practical\nscm>                     purposes.  Git even detects renames when a file has been\nscm>                     changed afterward the rename.  However, due to a peculiar\nscm>                     repository structure, renames are not recorded\nscm>                     explicitly, and Git has to deduce them (which works well\nscm>                     in practice).\nscm>                 </s>\n\nFirst, a correction to above statement.  It is not due to \"a peculiar\nrepository structure\", but due to \"a design decision\" (perhaps with\nlink to some explanation why it was implemented this way; I planned\nto make a wiki page about 'rename tracking' vs. 'rename detection'\nwith references to various mailing list messages etc., but to this\nday it was not created).\n\n\nSecond, we can think about how the above statement could be improved.\n\nFor example Git fullfils '0' even without rename detection, due to\nthe fact that it is whole-tree snapshot-based VCS.  From descriptions\nfor other version control systems (see \"Version Control System\nComparison\" subpage of \"Better SCM Initiative : Comparison\" at\nhttp://better-scm.berlios.de/comparison/comparison.html) it looks like\nat least some contributors thought that having '0' supported is enough\nto say 'Yes' to this question.\n\nGit uses rename detection, not rename tracking (usually file-id/inode\nbased) to be able to notify about renames in the diff / whatchanged /\ndiffstat or summary output.  So I would say that in practice (with\nsome unfortunate exceptions) Git fills '1', which means showing renames\nin whole project log well.\n\nWhen talking about rename detection for a single file history, here\nthe situation gets difficult.  On the one hand \"git log --follow <file>\"\nis a bit of hack and works only for simple histories, failing for\nexample on subtree merge; other example would be 'gitweb/gitweb.perl'\nfile in git repository, which '--follow' doesn't follow to initial\n'gitweb.cgi' file from what once been gitweb repository.  One has\nto use then \"git log -- <old name> <new name>\"; this is caused by the\nfact that git always concentrated more on full repository history, and\nby how path limiting works.  On the other hand Git has as far as I know\n_unique_ blame tool which is able to follow code movement; this covers\nmore than only following contents across wholesame file rename.  This\nfeature IMHO is best examined using \"git gui blame <file>\" or other\ngraphical blame/annotate viewers (QGit has one, for example).\n\n\nTo be honest git currently does not have _directory_ rename detection\n(which for example leads to some quirks in dealing with renames during\nmerge, to be more exact dealing with new files in a directory which\ngot renamed by other side); it currently supports directory renames\nby detecting renames of files it contains (path similarity is part of\nrename-detection similarity score).  But this is not insurmountable\nobstacle, and does not require changing design and tracking renames.\n\n\n...Now only put the above in a few short sentences to be used in\n\"Better SCM Initiative\" comparison table...\n\n\nscm>            </compare>\nscm>         </section>\nscm>         <section id=\"intelligent_renames\">\nscm>             <title>Intelligent Merging after Moves or Renames</title>\nscm>             <expl>\nscm>                 If the system keeps tracks of renames, does it support\nscm>                 intelligent merging of the files in the history after\nscm>                 the rename? (For example, changing a file in a renamed\nscm>                 directory, and trying to merge it).\nscm>             </expl>\n\nHere also the criterion is not completly clear.  The example helps\na little, but it should perhaps be expanded a little.  I don't know\nalso why the example is unnecessary complicated, with renaming\ndirectory; perhaps this version is shorter to describe.\n\nFor me \"Intelligent Merging after Moves or Renames\" consist of the\nfollowing items: merging renames, applying change to correct file,\ndealing with renamed directories, and new merge conflict types related\nto renames and similar things.\n\nLet me explain each concept with a little test case checking if given\nSCM support respective feature:\n * merging renames: if one side renamed file you should get rename on\n   merge; renaming a file and then merging that rename.\n     [on branch b]$ scm mv foo bar\n     [on branch a]$ scm commit ... # to not have fast-forward case\n     [on branch a]$ scm merge b\n     expected result> you have file 'bar', and do not have file 'foo'\n\n * applying change to correct file: if our side renamed a file (or, as\n   in above example rename directory it is in, which does rename full\n   pathname of a file indirectly), and possibly change it, and the other\n   side changed file, we would want merge to bring changes to file after\n   rename.\n     [on branch a]$ scm mv foo bar\n     [on branch a]$ edit bar && scm commit # optionally\n     [on branch b]$ edit foo\n     [on branch b]$ scm commit -m 'FOO'\n     [on branch a]$ scm merge b\n     expected result> you have changes made on branch 'b' to file 'foo'\n                      (commit 'FOO') in file 'bar'\n   Note that like in example in previous item all operations take place\n   _after_ branching point (after creation of branch b off branch a).\n\n   This is I guess what most people think when talking about\n   rename-aware (intelligent) merging.\n\n * renamed directories bring another complication (described for example\n   on Mark Shuttleworth blog in articles about DVCS, promoting Bazaar-NG),\n   namely how to deal with merging changes where other side creates\n   _new files_ in renamed directory.\n     [on branch a]$ scm mv subdir-foo/ subdir-bar/\n     [on branch b]$ scm add subdir-foo/baz\n     [on branch a]$ scm merge b\n     expected result> New file subdir-bar/baz\n   There is a bit of controversy about this feature, as for example in\n   some programming languages (e.g. Java) or in some project build tool\n   info it is not posible to simply move a file (or create new file in\n   different directory) without changing file contents.  Some say that\n   is better to fail than to do wrongly clean merge.\n\nscm>             <compare>\nscm>                 <s id=\"accurev\">\nscm>                     Unknown. FILL IN.\nscm>                 </s>\n\nAs you can see it is new criterion :-)\n\nscm>                 <s id=\"git\">\nscm>                     No. As detailed in the <a\nscm>                         href=\"http://git.or.cz/gitwiki/GitFaq#rename-tracking\">Git\nscm>                         FAQ</a>:\nscm>                     \"Git has a rename command git mv, but that is just a\nscm>                     convenience. The effect is indistinguishable from removing\nscm>                     the file and adding another with different name and the\nscm>                     same content.\"\nscm>                 </s>\n\nThis is of course NOT TRUE.  If the author bother checking (which\nwould be helped if there was available simple shell script, or simple\nPerl script, testing 'intelligent_renames' criterion) he/she would\nnotice that git does apply change to renamed file, both if file\nitself is renamed, and if directory it is in gets renamed.\n\nIf I understand correctly dealing with file renames and moving files\naround (one could say: refactoring directory hierarchy/structure) was\nmain reason (or one of main reasons) for adding rename detection to\nGit.  In practice it works quite well (which for the test mean testing\nwith large enough contents to be able to use similarity based rename\ndetection).\n\nWhat Git _currently_ doesn't support (at least for now, with lack of\ndetection of directories as a whole) is with adding new files to the\nrenamed directory, as described a bit above.\n\nscm>         <section id=\"copy\">\nscm>             <title>File and Directories Copies</title>\nscm>             <expl>\nscm>                 Does the version control system support copying\nscm>                 files or directories to a different location at the\nscm>                 repository level, while retaining the history?\nscm>             </expl>\n\nThe same complaint as with the \"File and Directory Moves or Renames\".\nWhat does \"support copying\" mean for SCM in question, in this context?\n\nscm>             <compare>\nscm>                 <s id=\"git\">No.  Copies are not supported.</s>\nscm>            </compare>\n\nTo a large extent NOT TRUE.  Copies _ARE_ supported in Git using the\nsame mechanism of similarity based detection as for renames.\n\nThere are however some caveats and limitations compared to rename\ndetection.  \n\nFirst, you have to enable copies detection.  While it is not uncommon\nto have rename detection turned on (I'm not sure if it is not on by\ndefault, for example for git-show; nevertheless you can turn it on for\ndiffs using diff.renames configuration variable, and for example gitweb\nweb interface by default detects renames), it is much less common to\nhave copies detection turned on by default, as it is more expensive\noperation.\n\nSecond, for performance reasons Git finds copies only if the original\nfile of the copy was modified in the same changeset.  You can search\nfor copies in all files, but it is much more expensive operation.\n\nOn the other hand git-blame can be asked to deal with code copying,\neven across files; as far as I know Git is the _only_ SCM which has\nfile line provenance annotation tool which supports this.\n\nscm>         <section id=\"repos_clone\">\nscm>             <title>Remote Repository Replication</title>\nscm>             <expl>\nscm>                 Does the system support cloning a remote repository to get\nscm>                 a functionally equivalent copy in the local system? That \nscm>                 should be done without any special access to the remote \nscm>                 server except for normal repository access.\nscm>             </expl>\n\nThis means either that SCM in question is distributed, or that there\nexists some replication / morroring tool (for centralized SCMs).\n\nscm>             <compare>\nscm>                 <s id=\"bazaar\">Yes.</s>\nscm>                 <s id=\"darcs\">Yes.</s>\nscm>                 <s id=\"mercurial\">Yes.</s>\nscm>                 <s id=\"monotone\">Yes.</s>\n\nscm>                 <s id=\"git\">Yes.  This is very intrinsic feature of Git.</s>\n\nIn fact this is 'very intrinsic feature' of each distributed SCM...\nwell, unless one takes into account difference between single-branch\nor workdir-per-branch distributed SCM and multiple-branch-per-repository\ndistributed SCM.  Then this is a bit more complicated.\n\nIn short: I think that simple 'Yes.' answer for Git would be better.\n\nscm>         <section id=\"push\">\nscm>             <title>Propagating Changes to Parent Repositories</title>\nscm>             <expl>\nscm>                 Can the system propagate changes from one repository to \nscm>                 another?\nscm>             </expl>\n\nO.K.\n\nscm>             <compare>\nscm>                 <s id=\"mercurial\">Yes.</s>\nscm>                 <s id=\"monotone\">Yes.</s>\nscm>                 <s id=\"git\">Yes.  (The Linux kernel development process uses this extremely often).</s>\nscm>             </compare>\nscm>         </section>\n\nI'm not sure if this comment is there really necessary.  I would avoid\nit, especially that as far as I understand Linux kernel development\nuses patch+email based system as extensively or even more extensively,\nat least onlietenants level.\n\nscm>         <section id=\"permissions\">\nscm>             <title>Repository Permissions</title>\nscm>             <expl>\nscm>                 Is it possible to define permissions on access to different\nscm>                 parts of a remote repository? Or is access open for all? \nscm>             </expl>\n\nSide note: Karl Fogel in his book \"Producing Open Source Software. \nHow to Run a Successful Free Software Project\" (http://producingoss.com)\nwrote basing on his work on _Subversion_ (which is centralized SCM),\nthat there are usually many advantages to use 'honor system' instead\nof repository permission, i.e. use social solution than technological\nsolution, see \"Chapter 3. Technical Infrastructure\", section \"Version\nControl\", subsection \"Authorization\"\n  http://producingoss.com/en/vc.html#vc-authz\n\nDistributed version control systems like Git, Mercurial or Bazaar-NG\noffers even wider selection of ways to implement 'honor system', and\nsolve \"Repository Permissions\" problem using social solution.\n\n[Here would be nice to have link to discussion of \"Prodicting OSS\" book\non git mailing list, and to article discussion it]\n\nscm>             <compare>\nscm>                 <s id=\"bazaar\">\nscm>                     Basic access control can be implemented through a\nscm>                     contributed hook script.  ACL support for the\nscm>                     Bazaar server is planned.\nscm>                 </s>\nscm>                 <s id=\"mercurial\">\nscm>                     Yes. It is possible to lock down repositories,\nscm>                     subdirectories, or files using hooks.\nscm>                 </s>\nscm>                 <s id=\"monotone\">\nscm>                     Yes. It is possible to restrict incoming changes\nscm>                     from certain sources to be performed only in certain\nscm>                     parts of the repository.\nscm>                 </s>\n[...]\nscm>                 <s id=\"git\">\nscm>                     No, but a single server can serve many repositories.\nscm>                     Also, UNIX permissions can be used to some extent.</s>\nscm>             </compare>\nscm>         </section>\n\nSide note: why Git entry was not word-wrapped like the entries for most\nother SCM, but used single long line? I have rewrapped it for better\nreadibility.\n\nFirst, there is possible to lock down repositories, using permissions\nof underlying protocols (SSH, WebDAV), or using additional tools like\nGitosis, ssh_acl or example hook contrib/hooks/update-paranoid.  It\nis possible to lock down (limit access to) branches and tags, which is\nnot mentioned as scope of this criterion, and I think is more important\nfeature.\n\nSecond, I think it is possible to restrict incoming changes from certain\nsources to subdirectories or files using hooks; but as far as I know\nthere doesn't exist any such example hook.\n\nAnd third, it is not as important for distributed SCM to have\nfine-grained technical solution when there are many social solutions\nto this problem; for example in Git when you do a pull from other\nrepository it would (usually) show you diffstat of changes, so you\ncan easily see if there were changes made outside some directory limits.\n\nscm>         <section id=\"changesets\">\nscm>             <title>Changesets' Support</title>\nscm>             <expl>\nscm>                 Does the repository support changesets? Changesets are a way\nscm>                 to group a number of modifications that are relevant to each\nscm>                 other in one atomic package, that can be cancelled or \nscm>                 propagated as needed.\nscm>             </expl>\n\nHere it is not entirely clean what creator of \"Better SCM Initiative\"\ncomparison table had on mind, what he meant by this.  Not all version\ncontrol systems are changeset based; some are snapshot based.  I guess\nthat for snapshot based SCM the above requirement is equivalent to\n\"Whole tree commits\".\n\nscm>             <compare>\nscm>                 <s id=\"cvs\">No. Changes are file-specific.</s>\nscm>                 <s id=\"subversion\">Partial support. There are implicit \nscm>                     changeset that are generated on each commit.\nscm>                 </s>\nscm>                 <s id=\"bazaar\">\nscm>                     Yes. Changesets are supported.\nscm>                 </s>\nscm>                 <s id=\"darcs\">\nscm>                     Yes. Changesets are supported.\nscm>                 </s>\nscm>                 <s id=\"mercurial\">\nscm>                     Yes. Changesets are supported.\nscm>                 </s>\nscm>                 <s id=\"monotone\">\nscm>                     Yes. Changesets are supported.\nscm>                 </s>\nscm>                 <s id=\"git\">\nscm>                     Yes, Changesets are supported, \nscm>                     and there's some flexibility in creating them.\nscm>                 </s>\nscm>            </compare>\nscm>         </section>\n\n[Again, Git part was re-wrapped for better readibility]\n\nIn my opition, such an _empty_ addition (\"there's some flexibility in\ncreating them\") is totally unnecessary; it adds no solid information\n(what does it mean \"some flexibility\") and should be removed.\n\nIf it was about Git being at the heart snapshot based rather than delta\n(changeset) based, then it should be reworded to make it clear \n(if deemed to be necessary).\n\nscm>         <section id=\"annotate\">\nscm>             <title>Tracking Line-wise File History</title>\nscm>             <expl>\nscm>                 Does the version control system have an option to track the\nscm>                 history of the file line-by-line? I.e., can it show for each line\nscm>                 at which revision it was most recently changed, and by whom?\nscm>             </expl>\n\nHere it would be nice to have example of such output, but I think\neveryone knows what this criterion means in the term of SCM features.\n\nscm>             <compare>\nscm>                 <s id=\"git\">Yes. (git blame).</s>\nscm>            </compare>\n\nPerhaps we could also add that git-blame supports (if requested)\ntracking changes across code movement and code copying (crossing\nfile boundaries if necessary, and can ignore changes in whitespace.\nAnd there is also \"pickaxe\" search, which can find deleted contents,\nwhich is one of major limitations of usability of line-wise file\nhistory (line provenance) annotations.\n\nOn the other hand because Git is based towards whole project history,\nand not per file history, git-blame is slow.  To migitate that there\nis incremental blame mode used to reduce latency in graphical blame\nviewers like \"git gui blame\", contrib/blameview, or the one in QGit.\n\n\nscm>     <section id=\"features\">\nscm>         <title>Features</title>\nscm>         <section id=\"work_on_dir\">\nscm>             <title>Ability to Work only on One Directory of the Repository</title>\nscm>             <expl>\nscm>                 Can the version control system checkout only one directory of\nscm>                 the repository? Or restrict the check-ins to only one \nscm>                 directory?\nscm>             </expl>\n\nThis is combination of \"restricted check-ins\" and so called \"partial\ncheckout\", or \"sparse checkout\", or \"narrow checkout\".\n\nscm>             <compare>\nscm>                 <s id=\"bazaar\">For checkouts: No. For checkins: Yes.</s>\nscm>                 <s id=\"darcs\">\nscm>                     It is possible to commit only a certain directory. \nscm>                     However, one must check out the entire repository as a\nscm>                     whole.\nscm>                 </s>\nscm>                 <s id=\"mercurial\">\nscm>                     It is possible to commit changes only in a subset of the\nscm>                     tree. There are plans for partial checkouts.\nscm>                 </s>\nscm>                 <s id=\"monotone\">\nscm>                     It is possible to commit changes only in a subset of the\nscm>                     tree. However, one must extract the entire tree to work\nscm>                     on it.\nscm>                 </s>\n\nscm>                 <s id=\"git\">\nscm>                     No.  However, commits could be restricted somewhat,\nscm>                     see the \"Repository Permissions\".\nscm>                 </s>\n\nI think (depending of course on \"Repository Permissions\" part) that the\npart about 'work_on_dir' for checkins should be made more clear.  Note\nalso that for this criterion, for distributed version control systems,\none should consider difference between comitting changes (pre-commit\nhook), and publishing changes (update and post-receive hook).\n\nI would also add that \"There are plans for partial checkout\" (or rather\n\"sparse\" checkouts), where \"plans\" for this mean \"preliminary work\".\nAlthough implementing this idea seems stalled a bit.  I guess that when\nGit acquires ability to do sparse checkout, it would have it done\ncorrectly (c.f. git submodules and svn:externals).\n\n\nscm>         <section id=\"tracking_uncommited_changes\">\nscm>             <title>Tracking Uncommited Changes</title>\nscm>             <expl>\nscm>                 Does the software have an ability to track the changes in the\nscm>                 working copy that were not yet committed to the repository?\nscm>             </expl>\n\nThis also should be made more clean.  Does it mean for example ability\nto tell which files have changed, or ability to diff working copy to\neither last comitted changes, or to any revision available in repository?\n\nscm>             <compare>\nscm>                 <s id=\"cvs\">Yes. Using cvs diff</s>\n\nscm>                 <s id=\"git\">\nscm>                     Yes.\n\n\"Using git diff\"?  The problem is with [possible] difference between\n\"git diff\", \"git diff HEAD\", \"git diff --cached\".\n\nscm>\nscm>                     Also, branches are very lightweight in Git, and\nscm>                     could be considered a kind of storage for \"uncommitted\"\nscm>                     code in some workflows.\nscm>                 </s>\n\nI'm not sure if it is worth mentioning here _explicit_ staging area\n(index) available in Git.\n\nBTW. it would be nice if \"git gui\", the Git GUI distributed with Git,\nhad some graphical diff (and diff3) view tool.\n\n\nscm>         <section id=\"per_file_commit_messages\">\nscm>             <title>Per-File Commit Messages</title>\nscm>             <expl>\nscm>                 Does the system have a way to assign a per-file commit message\nscm>                 to the changeset, as well as a per-changeset message?\nscm>             </expl>\nscm>             <compare>\nscm>                 <s id=\"git\">No. Commit messages are per changeset.</s>\nscm>            </compare>\nscm>         </section>\nscm>     </section>\n\nO.K.\n\nBy the way, does anybody know what happened to the 'commit annotations',\naka 'notes' idea?\n\n\nscm>     <section id=\"technical_status\">\nscm>         <title>Technical Status</title>\nscm>         <section id=\"documentation\">\nscm>             <title>Documentation</title>\nscm>             <expl>\nscm>                 How well is the system documented? How easy is it to\nscm>                 get started using it?\nscm>             </expl>\nscm>             <compare>\nscm>                 <s id=\"git\">\nscm>                     Medium. The short help is too terse and obscure.\nscm>                     The man pages are extensive, but tend to be confusing.\nscm>                     The are many tutorials.\nscm>                 </s>\nscm>             </compare>\nscm>         </section>\n\nThat of course depends on your opinion.  I would say \"Good\", now that\nthere is \"Git User's Manual\" distributed with Git, and now that there\nstarted semi-official \"Git Community Book\" (http://book.git-scm.com).\n\n[Perhaps we could use some survey results do defend that fact.]\n\n\nscm>         <section id=\"ease_of_deployment\">\nscm>             <title>Ease of Deployment</title>\nscm>             <expl>\nscm>                 How easy is it to deploy the software? What are\nscm>                 the dependencies and how can they be satisfied?\nscm>             </expl>\nscm>             <compare>\nscm>                <s id=\"git\">\nscm>                    Good.  Binary packages are available\nscm>                    for modern platforms.  C compiler and Perl are\nscm>                    required. Requires Cygwin on Windows, and has some\nscm>                    UNIXisms.\nscm>                </s>\nscm>            </compare>\n\nOn one hand there are are still a few important Git commands like\ngit-am (for patch+email based workflows), git-bisect, git-pull,\ngit-rebase[1], git-stash and internal parts of git-merge[2] which do\nrequire POSIX shell, and what is inherent in shell scripting some core\nutilities like grep, sed, cat; also for some workflows ssh is needed.\nThis is gets reduced bit by bit due to builtinification efforts.\n\nOn the other hand thanks to msysGit project Git does not require Cygwin\nto be installed on MS Windows.\n\nI would also remove \"has some UNIXisms\" which doesn't bring IMVHO\nany information.\n\n[1] This I hope would change thanks to builtin git-sequencer from GSoC\n    (or rather post-GSoC work).\n[2] This I hope would change thanks to post-GSoC expansion on \n    builtin git-merge\n\n\nscm>         <section id=\"command_set\">\nscm>             <title>Command Set</title>\nscm>             <expl>\nscm>                 What is the command set? How compatible is it with\nscm>                 the commands of CVS (the current open-source defacto\nscm>                 standard)?\nscm>             </expl>\n\nSidenote: I'm not sure if CVS is still \"defacto standard\"; additionally\ndistributed SCM have enable vastly different workflows, so it is hard\nto compare their command set to that of CVS, and such comparison covers\nonly subset of DSCM commands.\n\nscm>             <compare>\nscm>                 <s id=\"subversion\">\nscm>                     A CVS-like command set which is easy to get used to\nscm>                     for CVS-users.\nscm>                 </s>\nscm>                 <s id=\"bitkeeper\">\nscm>                     A CVS-like command set with some easy-to-get-used-to\nscm>                     complications due to its different way of work and \nscm>                     philosophy.\nscm>                 </s>\nscm>                 <s id=\"bazaar\">\nscm>                 <s id=\"mercurial\">\nscm>                 <s id=\"monotone\">\nscm>                     Tries to follow CVS conventions, but deviates\nscm>                     where there is a different design.\nscm>                 </s>\nscm>                 <s id=\"perforce\">\nscm>                     Very extensive but not compatible with CVS.\nscm>                 </s>\n\nscm>                 <s id=\"git\">\nscm>                     Command set is very feature-rich,\nscm>                     and not compatible with CVS.\nscm>                 </s>\n\nI wouldn't say that situation with Git is different from situation with\nMercurial, Bazaar-NG and Monotone, especially with respect to subset of\ncommands which have equivalents in CVS.  Although Git doesn't \"try to\nfollow CVS conventions\", it does follow BitKeeper convention, then by\ntransitive also CVS conventions.  I would agree with \"feature-rich\"\ncomment, though ;-)\n\n\nscm>         <section id=\"networking\">\nscm>             <title>Networking Support</title>\nscm>             <expl>\nscm>                 How good is the networking integration of the system?\nscm>                 How compliant is it with existing protocols and infra-structure?\nscm>             </expl>\nscm>             <compare>\nscm>                 <s id=\"bazaar\">\nscm>                     Excellent. Works natively over HTTP (read-only),\nscm>                     FTP and SFTP without having Bazaar installed at\nscm>                     the remote end.  Works over HTTP, SSH and a custom\nscm>                     protocol when talking to a remote Bazaar\nscm>                     server. Supports RSYNC and WebDAV (experimental)\nscm>                     through plugins.\nscm>                 </s>\nscm>                 <s id=\"mercurial\">\nscm>                     Excellent.  Uses HTTP or ssh.  Remote access also\nscm>                     works safely without locks over read-only network\nscm>                     filesystems.\nscm>                 </s>\nscm>                 <s id=\"git\">\nscm>                     Excellent.  Can use native Git protocol,\nscm>                     but works over rsync, ssh, HTTP and HTTPS also.\nscm>                 </s>\n\nIt could be written differently, but O.K.\n\n\nscm>         <section id=\"portability\">\nscm>             <title>Portability</title>\nscm>             <expl>\nscm>                 How portable is the version-control system to various \nscm>                 operating systems, computer architectures, and other\nscm>                 types of systems?\nscm>             </expl>\nscm>             <compare>\nscm>               <s id=\"git\">\nscm>                  The client works on most UNIXes, but not on native\nscm>                  MS-Windows. The Cygwin build seems to be workable, though.\nscm>               </s>\nscm>             </compare>\nscm>         </section>\nscm>     </section>\n\n\"Most UNIXes\" (or is it Unices)?  On what modern UNIX Git doesn't work?\n\nAgain, the author of of entries for Git doesn't seem to know about\nmsysGit project, which is native MS Windows implementation (utilizing\nMSYS / MinGW).  And what does \"Cygwin build _seems_ to be workable\"\nmean?\n\nThe entry for Git lacks also single word descriptions, like \"Excellent\",\n\"Very good\", \"Good\", \"Medium\", that most other SCM have in this part\n(and \"Windows only\" for some).\n\n\nscm>     <section id=\"user_interaces\">\nscm>         <title>User Interfaces</title>\nscm>         <section id=\"web_interface\">\nscm>             <title>Web Interface</title>\nscm>             <expl>\nscm>                 Does the system have a WWW-based interface that can be\nscm>                 used to browse the tree and the various revisions of the\nscm>                 files, perform arbitrary diffs, etc?\nscm>             </expl>\nscm>             <compare>\nscm>                 <s id=\"git\">\nscm>                     Yes.  Gitweb is included in distribution.\nscm>                 </s>\nscm>             </compare>\nscm>         </section>\n\nFor other SCMs there are listed many different web interfaces.\nSo I would perhaps put here a list, like in\n  http://git.or.cz/gitwiki/InterfacesFrontendsAndTools#head-e5a6762d6aed31c5a2034d52c1733ead46402c31\n\n(There is slight problem with Gitweb, which has neither homepage nor\nseparate repository; we can use Gitweb page on Git Wiki, or README\nfrom git.git repository via gitweb ;-).\n\n\nscm>         <section id=\"availability_of_guis\">\nscm>             <title>Availability of Graphical User-Interfaces.</title>\nscm>             <expl>\nscm>                 What is the availability of graphical user-interfaces for\nscm>                 the system? How many GUI clients are present for it?\nscm>             </expl>\nscm>             <compare>\nscm>                 <s id=\"git\">\nscm>                     Gitk is included in distribution.  \nscm>                     QGit and Git-gui tools are also available.\nscm>                 </s>\nscm>            </compare>\nscm>         </section>\nscm>     </section>\n\ngit-gui is _also_ included in distribution. So I would say:\n\n                 <s id=\"git\">\n                     Gitk and git-gui are included in distribution.  \n                     <a href=\"[1]\">Other tools</a> are also available.\n                 </s>\n\n[1] http://git.or.cz/gitwiki/InterfacesFrontendsAndTools#head-cee25e252efc24b245482fe9fa8d24ff5d5af1d6\n\n\nscm>     <section id=\"license\">\nscm>         <title>License</title>\nscm>         <expl>\nscm>             What are the licensing terms for the software? \nscm>         </expl>\nscm>         <compare>\nscm>             <s id=\"git\">GNU GPL v2 (open source).</s>\nscm>         </compare>\n\nO.K.\n\n-- \nJakub Narebski\nPoland\n"},{"id":"90676","messageId":"20080914144306.GF28210@dpotapov.dyndns.org","threadId":"15518","inReplyTo":"200809131906.18746.jnareb@gmail.com","subject":"Re: Git at Better SCM Initiative comparison of VCS (long)","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2008-09-14T14:43:06Z","receivedAt":"2008-09-14T14:43:06Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"Hello Jakub,\n\nI have added Alexey Mahotkin in CC, who is allegedly the author of that\ninformation about Git that you can read on the better-scm site.\n\nOn Sat, Sep 13, 2008 at 07:06:16PM +0200, Jakub Narebski wrote:\n> \n> I have thought about trying yet another time... but Git was already\n> added; see http://better-scm.berlios.de/news/changes-2008-08-07/\n\nInteresting, the site still mentions Git as missing in a few places.\nFor instance, when you click on Git in the list of alternatives, you\nget this: http://better-scm.berlios.de/alternatives/git/\nand then when you got to FAQ, you can read this:\n\n| The reason it's not there is that while many people have complained\n| about its absense, no one suitable has volunteered to become its\n| champion and supplied a good enough patch. If you have a substantial\n| amount of git expertise, have good English writing skills, and wish to\n| volunteer, then we'll be happy to hear from you. If not - at least don't\n| complain about it.\n|\n| In addition to everything that was said here, it seems that the\n| originator and maintainer of the site and comparison is now banned\n| from sending messages to vger.kernel.org, which hosts several\n| Linux-kernel-related mailing-lists, including the git one. This has\n| interfered with some of his Linux-related open-source work, including\n| trying to find a \"Better SCM\" maintainer for git. This is unfortunate,\n| but changing this situation, is currently beyond his control.\n\nSource: http://better-scm.berlios.de/faq/#git-missing\n\nI am surprised to hear that Shlomi Fish is banned...\n\n> scm>     <section id=\"repos_operations\">\n> scm>         <title>Repository Operations</title>\n> scm>         <section id=\"atomic_commits\">\n> scm>             <title>Atomic Commits</title>\n> scm>             <expl>\n> scm>                 Support for atomic commits means that if an\n> scm>                 operation on the repository is interrupted\n> scm>                 in the middle, the repository will not be\n> scm>                 left in an inconsistent state. Are the\n> scm>                 check-in operations atomic, or can\n> scm>                 interrupting an operation leave the\n> scm>                 repository in an intermediate state?\n> scm>             </expl>\n> \n> Here I think the explanation of a criterion (feature) is clear enough.\n> I might have added that \"interruption\" include killing of a process\n> during for example commit, lack of disk space for a full commit, or\n> a network fail during network operation (fetch or push, or equivalent).\n\nMy initial reaction was to say that killing a process with -9 is not\nwhat you expect to see in practice, but a second later, I realized how\nwrong I was. Lack of memory may cause that the process gets killed with\n-9, and it has been observed in practice (at least, in case of Mercury\nrepo): http://norman.walsh.name/2007/08/09/mercurial\n\nAnother thing that is not clear in the above criterion is what exactly\n\"inconsistent state\" (or \"intermediate state\") means. For instance, if\nGit gets killed during commit, you may have to remove .git/index.lock\nmanually. AFAIK, Mercury leaves the 'journal' file and you have to\nrun \"hg recovery\". Does it mean that the commit is not atomic?\n\nAnother thing here is that \"git commit\" is local, so I am not sure\nif this question includes network operations...\n\n> scm>         <section id=\"move\">\n> scm>             <title>Files and Directories Moves or Renames</title>\n> scm>             <expl>\n> scm>                 Does the system support moving a file or directory to\n> scm>                 a different location while still retaining the history\n> scm>                 of the file? <b>Note:</b> also see the next section\n> scm>                 about intelligent merging of renamed paths.\n> scm>             </expl>\n> \n> In my opinion this criterion is next to worthess without more in depth\n> clarification of what does it mean to \"support\" moves or renames; as\n> entries for different systems are written by different people, if it\n> is not clear how to check if some feature is supported, some might\n> write 'no' for some system A, and some other person can write 'yes'\n> for other system B, even if the support is better in system A than in\n> system B (and would be considered enough, i.e. 'yes' answer, by the\n> creator of this criterion).\n> \n> For me the support for renames/moves and copying (see next section)\n> means that:\n> \n>  0.) When examining or going to some point in the history (some old\n>      revision/version of a project) the state you get is _exactly_\n>      the same as it was at that time, exactly the same as it was\n>      recorded (comitted) then.\n> \n>      For example tricks with moving *,v files in the CVS repository\n>      break this assertion.\n\nIMHO, the above assertion is assumed when we talk about renaming, as\nthe system that is not capable of that will not be qualified as an\nSCM. Yet, there is still plenty way to interpret the above criterion.\nEven in CVS, the history of the file does not disappear when you move\na file. You can just write, this file move was renamed from old-name,\nso anyone can get old history without any problem. Of course, it will\nrequire some an additional step taken manually. But if the requirement\nis to see all log history with one $scm log command, you can just copy\nold log into log of a newly added file. Of course, you cannot run $scm\nannotate on that file and see who changed what line, but there is no\nsuch a requirement above.\n\nSo, I agree, it should be better defined.\n\n> \n>  1.) When examining history of a project as a whole version control\n>      system tells you that file was renamed (moved). I would consider\n>      having there renaming represented as copy + delete to be only\n>      a partial support of this feature.\n\nIf files moving is interpreted in the sense of preserving the old history\nthen copy + delete fully satisfies that criterion.\n\nHowever, if you defined support of file movement as ability to see that\nsome file when you look at the history of the whole project then\ncertainly copy + delete representation would not satisfy it.\n\nSo, perhaps, it should be two separate points:\n- ability to preserve history of rename (with detail clarification\n  of what it means)\n- ability to show renames in the project history\n\n> \n> scm>                 <s id=\"git\">\n> scm>                     Renames are supported for most practical\n> scm>                     purposes.  Git even detects renames when a file has been\n> scm>                     changed afterward the rename.  However, due to a peculiar\n> scm>                     repository structure, renames are not recorded\n> scm>                     explicitly, and Git has to deduce them (which works well\n> scm>                     in practice).\n> scm>                 </s>\n> \n> First, a correction to above statement.  It is not due to \"a peculiar\n> repository structure\", but due to \"a design decision\" (perhaps with\n> link to some explanation why it was implemented this way; I planned\n> to make a wiki page about 'rename tracking' vs. 'rename detection'\n> with references to various mailing list messages etc., but to this\n> day it was not created).\n\nAgreed.\n\n> \n> \n> Second, we can think about how the above statement could be improved.\n> \n\n<long and detail explanation of how git works>\n\n> \n> ...Now only put the above in a few short sentences to be used in\n> \"Better SCM Initiative\" comparison table...\n\nGit tracks content rather than file-ids, and therefore it uses heuristics\nfor rename detection.  This approach has an advantage of being able to\npreserve history for code lines between files, which usually happens much\nmore often than file renaming.\n\n> scm>                 <s id=\"git\">\n> scm>                     No. As detailed in the <a\n> scm>                         href=\"http://git.or.cz/gitwiki/GitFaq#rename-tracking\">Git\n> scm>                         FAQ</a>:\n> scm>                     \"Git has a rename command git mv, but that is just a\n> scm>                     convenience. The effect is indistinguishable from removing\n> scm>                     the file and adding another with different name and the\n> scm>                     same content.\"\n> scm>                 </s>\n> \n> This is of course NOT TRUE.  If the author bother checking (which\n> would be helped if there was available simple shell script, or simple\n> Perl script, testing 'intelligent_renames' criterion) he/she would\n> notice that git does apply change to renamed file, both if file\n> itself is renamed, and if directory it is in gets renamed.\n\nSure. But it just demonstrates that the line of reasoning, which was\nclearly based on unstated assumption of how file-id tracking performs\nmerge in this situation leads to the wrong conclusion for Git as it is\nthe content tracking system, so Git does that differently.\n\nPerhaps, it would make sense to extend GitFaq to better cover that\npoint, because people with other SCM background could easily conclude\nthat Git cannot do \"intelligent merge\" after reading about git-mv.\n\n> scm>         <section id=\"changesets\">\n> scm>             <title>Changesets' Support</title>\n> scm>             <expl>\n> scm>                 Does the repository support changesets? Changesets are a way\n> scm>                 to group a number of modifications that are relevant to each\n> scm>                 other in one atomic package, that can be cancelled or \n> scm>                 propagated as needed.\n> scm>             </expl>\n> \n> Here it is not entirely clean what creator of \"Better SCM Initiative\"\n> comparison table had on mind, what he meant by this.  Not all version\n> control systems are changeset based; some are snapshot based.  I guess\n> that for snapshot based SCM the above requirement is equivalent to\n> \"Whole tree commits\".\n\nYes, it is irrelevant to being changeset or snapshot based. It is\nwhether modification to more than one file can be commited (and\npropogated) atomically. I also suppose that those changes should be\nshown in history as a single change (not many changes too different\nfiles that took place in the same time and the same commit comment).\n\nHowever, the whole tree commit is a more strict requirement than\njust being able to commit a group of changes atomically. For example,\n\"svn ci\" creates a changeset and atomically store all its modification\non the server. Yet, it is not the whole tree commit, because the result\ntree may differ from the tree that you commiting (files that are not\nmodified by changeset may differ).\n\n> scm>                 <s id=\"git\">\n> scm>                     Yes, Changesets are supported, \n> scm>                     and there's some flexibility in creating them.\n> scm>                 </s>\n> scm>            </compare>\n> scm>         </section>\n> \n> [Again, Git part was re-wrapped for better readibility]\n> \n> In my opition, such an _empty_ addition (\"there's some flexibility in\n> creating them\") is totally unnecessary; it adds no solid information\n> (what does it mean \"some flexibility\") and should be removed.\n\nAgreed. I suspect the author implied by that Git allows to stage\nand commit separately chunk without commiting the whole file.\nYet, as it is worded above, it is useless.\n\n> scm>         <section id=\"tracking_uncommited_changes\">\n> scm>             <title>Tracking Uncommited Changes</title>\n> scm>             <expl>\n> scm>                 Does the software have an ability to track the changes in the\n> scm>                 working copy that were not yet committed to the repository?\n> scm>             </expl>\n> \n> This also should be made more clean.  Does it mean for example ability\n> to tell which files have changed, or ability to diff working copy to\n> either last comitted changes, or to any revision available in repository?\n\nAlso, ability to diff one or more specified files in the working copy to\nsome specified revision.\n\n> scm>     <section id=\"technical_status\">\n> scm>         <title>Technical Status</title>\n> scm>         <section id=\"documentation\">\n> scm>             <title>Documentation</title>\n> scm>             <expl>\n> scm>                 How well is the system documented? How easy is it to\n> scm>                 get started using it?\n> scm>             </expl>\n> scm>             <compare>\n> scm>                 <s id=\"git\">\n> scm>                     Medium. The short help is too terse and obscure.\n> scm>                     The man pages are extensive, but tend to be confusing.\n> scm>                     The are many tutorials.\n> scm>                 </s>\n> scm>             </compare>\n> scm>         </section>\n> \n> That of course depends on your opinion.  I would say \"Good\", now that\n> there is \"Git User's Manual\" distributed with Git, and now that there\n> started semi-official \"Git Community Book\" (http://book.git-scm.com).\n\nInteresting that versioncontrolblog, which, if I am not mistaken, is\nAlexey's site, states for Git Documentation:\n\n| Good. There is extensive documentation for every command, and many\n| tutorials.\n\nhttp://www.versioncontrolblog.com/comparison/Git/index.html\n\nSo, I am not sure were the word \"Medium\" came from.\n\n\nDmitry\n"},{"id":"90677","messageId":"bb5b640b0809140809g1aff9047qd6baf6cd66d23ec6@mail.gmail.com","threadId":"15518","inReplyTo":"20080914144306.GF28210@dpotapov.dyndns.org","subject":"Re: Git at Better SCM Initiative comparison of VCS (long)","fromName":"Alexey Mahotkin","fromEmail":"squadette@gmail.com","sentAt":"2008-09-14T15:09:36Z","receivedAt":"2008-09-14T15:09:36Z","isPatch":false,"sender":{"key":"squadette@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3052?v=4"},"body":"Hi,\n\nI've written the version which is on http://versioncontrolblog.com and\nsent it to Mr. Shlomi Fish several months ago.     He has extensively\nre-written my text, making it more \"neutral\", and published it on\nbetter-scm.  I do not agree with some of the changes he made, but I\ndid not insist.  :)\n\nOccasionally I update my text with the current version at better-scm,\nbut this has not happened for some time, and it still contains my\noriginal version.\n\nIs there anything I can do to improve the state of things in any way? :)\n\nOn Sun, Sep 14, 2008 at 6:43 PM, Dmitry Potapov <dpotapov@gmail.com> wrote:\n> Hello Jakub,\n>\n> I have added Alexey Mahotkin in CC, who is allegedly the author of that\n> information about Git that you can read on the better-scm site.\n>\n> On Sat, Sep 13, 2008 at 07:06:16PM +0200, Jakub Narebski wrote:\n>>\n>> I have thought about trying yet another time... but Git was already\n>> added; see http://better-scm.berlios.de/news/changes-2008-08-07/\n>\n> Interesting, the site still mentions Git as missing in a few places.\n> For instance, when you click on Git in the list of alternatives, you\n> get this: http://better-scm.berlios.de/alternatives/git/\n> and then when you got to FAQ, you can read this:\n>\n> | The reason it's not there is that while many people have complained\n> | about its absense, no one suitable has volunteered to become its\n> | champion and supplied a good enough patch. If you have a substantial\n> | amount of git expertise, have good English writing skills, and wish to\n> | volunteer, then we'll be happy to hear from you. If not - at least don't\n> | complain about it.\n> |\n> | In addition to everything that was said here, it seems that the\n> | originator and maintainer of the site and comparison is now banned\n> | from sending messages to vger.kernel.org, which hosts several\n> | Linux-kernel-related mailing-lists, including the git one. This has\n> | interfered with some of his Linux-related open-source work, including\n> | trying to find a \"Better SCM\" maintainer for git. This is unfortunate,\n> | but changing this situation, is currently beyond his control.\n>\n> Source: http://better-scm.berlios.de/faq/#git-missing\n>\n> I am surprised to hear that Shlomi Fish is banned...\n>\n>> scm>     <section id=\"repos_operations\">\n>> scm>         <title>Repository Operations</title>\n>> scm>         <section id=\"atomic_commits\">\n>> scm>             <title>Atomic Commits</title>\n>> scm>             <expl>\n>> scm>                 Support for atomic commits means that if an\n>> scm>                 operation on the repository is interrupted\n>> scm>                 in the middle, the repository will not be\n>> scm>                 left in an inconsistent state. Are the\n>> scm>                 check-in operations atomic, or can\n>> scm>                 interrupting an operation leave the\n>> scm>                 repository in an intermediate state?\n>> scm>             </expl>\n>>\n>> Here I think the explanation of a criterion (feature) is clear enough.\n>> I might have added that \"interruption\" include killing of a process\n>> during for example commit, lack of disk space for a full commit, or\n>> a network fail during network operation (fetch or push, or equivalent).\n>\n> My initial reaction was to say that killing a process with -9 is not\n> what you expect to see in practice, but a second later, I realized how\n> wrong I was. Lack of memory may cause that the process gets killed with\n> -9, and it has been observed in practice (at least, in case of Mercury\n> repo): http://norman.walsh.name/2007/08/09/mercurial\n>\n> Another thing that is not clear in the above criterion is what exactly\n> \"inconsistent state\" (or \"intermediate state\") means. For instance, if\n> Git gets killed during commit, you may have to remove .git/index.lock\n> manually. AFAIK, Mercury leaves the 'journal' file and you have to\n> run \"hg recovery\". Does it mean that the commit is not atomic?\n>\n> Another thing here is that \"git commit\" is local, so I am not sure\n> if this question includes network operations...\n>\n>> scm>         <section id=\"move\">\n>> scm>             <title>Files and Directories Moves or Renames</title>\n>> scm>             <expl>\n>> scm>                 Does the system support moving a file or directory to\n>> scm>                 a different location while still retaining the history\n>> scm>                 of the file? <b>Note:</b> also see the next section\n>> scm>                 about intelligent merging of renamed paths.\n>> scm>             </expl>\n>>\n>> In my opinion this criterion is next to worthess without more in depth\n>> clarification of what does it mean to \"support\" moves or renames; as\n>> entries for different systems are written by different people, if it\n>> is not clear how to check if some feature is supported, some might\n>> write 'no' for some system A, and some other person can write 'yes'\n>> for other system B, even if the support is better in system A than in\n>> system B (and would be considered enough, i.e. 'yes' answer, by the\n>> creator of this criterion).\n>>\n>> For me the support for renames/moves and copying (see next section)\n>> means that:\n>>\n>>  0.) When examining or going to some point in the history (some old\n>>      revision/version of a project) the state you get is _exactly_\n>>      the same as it was at that time, exactly the same as it was\n>>      recorded (comitted) then.\n>>\n>>      For example tricks with moving *,v files in the CVS repository\n>>      break this assertion.\n>\n> IMHO, the above assertion is assumed when we talk about renaming, as\n> the system that is not capable of that will not be qualified as an\n> SCM. Yet, there is still plenty way to interpret the above criterion.\n> Even in CVS, the history of the file does not disappear when you move\n> a file. You can just write, this file move was renamed from old-name,\n> so anyone can get old history without any problem. Of course, it will\n> require some an additional step taken manually. But if the requirement\n> is to see all log history with one $scm log command, you can just copy\n> old log into log of a newly added file. Of course, you cannot run $scm\n> annotate on that file and see who changed what line, but there is no\n> such a requirement above.\n>\n> So, I agree, it should be better defined.\n>\n>>\n>>  1.) When examining history of a project as a whole version control\n>>      system tells you that file was renamed (moved). I would consider\n>>      having there renaming represented as copy + delete to be only\n>>      a partial support of this feature.\n>\n> If files moving is interpreted in the sense of preserving the old history\n> then copy + delete fully satisfies that criterion.\n>\n> However, if you defined support of file movement as ability to see that\n> some file when you look at the history of the whole project then\n> certainly copy + delete representation would not satisfy it.\n>\n> So, perhaps, it should be two separate points:\n> - ability to preserve history of rename (with detail clarification\n>  of what it means)\n> - ability to show renames in the project history\n>\n>>\n>> scm>                 <s id=\"git\">\n>> scm>                     Renames are supported for most practical\n>> scm>                     purposes.  Git even detects renames when a file has been\n>> scm>                     changed afterward the rename.  However, due to a peculiar\n>> scm>                     repository structure, renames are not recorded\n>> scm>                     explicitly, and Git has to deduce them (which works well\n>> scm>                     in practice).\n>> scm>                 </s>\n>>\n>> First, a correction to above statement.  It is not due to \"a peculiar\n>> repository structure\", but due to \"a design decision\" (perhaps with\n>> link to some explanation why it was implemented this way; I planned\n>> to make a wiki page about 'rename tracking' vs. 'rename detection'\n>> with references to various mailing list messages etc., but to this\n>> day it was not created).\n>\n> Agreed.\n>\n>>\n>>\n>> Second, we can think about how the above statement could be improved.\n>>\n>\n> <long and detail explanation of how git works>\n>\n>>\n>> ...Now only put the above in a few short sentences to be used in\n>> \"Better SCM Initiative\" comparison table...\n>\n> Git tracks content rather than file-ids, and therefore it uses heuristics\n> for rename detection.  This approach has an advantage of being able to\n> preserve history for code lines between files, which usually happens much\n> more often than file renaming.\n>\n>> scm>                 <s id=\"git\">\n>> scm>                     No. As detailed in the <a\n>> scm>                         href=\"http://git.or.cz/gitwiki/GitFaq#rename-tracking\">Git\n>> scm>                         FAQ</a>:\n>> scm>                     \"Git has a rename command git mv, but that is just a\n>> scm>                     convenience. The effect is indistinguishable from removing\n>> scm>                     the file and adding another with different name and the\n>> scm>                     same content.\"\n>> scm>                 </s>\n>>\n>> This is of course NOT TRUE.  If the author bother checking (which\n>> would be helped if there was available simple shell script, or simple\n>> Perl script, testing 'intelligent_renames' criterion) he/she would\n>> notice that git does apply change to renamed file, both if file\n>> itself is renamed, and if directory it is in gets renamed.\n>\n> Sure. But it just demonstrates that the line of reasoning, which was\n> clearly based on unstated assumption of how file-id tracking performs\n> merge in this situation leads to the wrong conclusion for Git as it is\n> the content tracking system, so Git does that differently.\n>\n> Perhaps, it would make sense to extend GitFaq to better cover that\n> point, because people with other SCM background could easily conclude\n> that Git cannot do \"intelligent merge\" after reading about git-mv.\n>\n>> scm>         <section id=\"changesets\">\n>> scm>             <title>Changesets' Support</title>\n>> scm>             <expl>\n>> scm>                 Does the repository support changesets? Changesets are a way\n>> scm>                 to group a number of modifications that are relevant to each\n>> scm>                 other in one atomic package, that can be cancelled or\n>> scm>                 propagated as needed.\n>> scm>             </expl>\n>>\n>> Here it is not entirely clean what creator of \"Better SCM Initiative\"\n>> comparison table had on mind, what he meant by this.  Not all version\n>> control systems are changeset based; some are snapshot based.  I guess\n>> that for snapshot based SCM the above requirement is equivalent to\n>> \"Whole tree commits\".\n>\n> Yes, it is irrelevant to being changeset or snapshot based. It is\n> whether modification to more than one file can be commited (and\n> propogated) atomically. I also suppose that those changes should be\n> shown in history as a single change (not many changes too different\n> files that took place in the same time and the same commit comment).\n>\n> However, the whole tree commit is a more strict requirement than\n> just being able to commit a group of changes atomically. For example,\n> \"svn ci\" creates a changeset and atomically store all its modification\n> on the server. Yet, it is not the whole tree commit, because the result\n> tree may differ from the tree that you commiting (files that are not\n> modified by changeset may differ).\n>\n>> scm>                 <s id=\"git\">\n>> scm>                     Yes, Changesets are supported,\n>> scm>                     and there's some flexibility in creating them.\n>> scm>                 </s>\n>> scm>            </compare>\n>> scm>         </section>\n>>\n>> [Again, Git part was re-wrapped for better readibility]\n>>\n>> In my opition, such an _empty_ addition (\"there's some flexibility in\n>> creating them\") is totally unnecessary; it adds no solid information\n>> (what does it mean \"some flexibility\") and should be removed.\n>\n> Agreed. I suspect the author implied by that Git allows to stage\n> and commit separately chunk without commiting the whole file.\n> Yet, as it is worded above, it is useless.\n>\n>> scm>         <section id=\"tracking_uncommited_changes\">\n>> scm>             <title>Tracking Uncommited Changes</title>\n>> scm>             <expl>\n>> scm>                 Does the software have an ability to track the changes in the\n>> scm>                 working copy that were not yet committed to the repository?\n>> scm>             </expl>\n>>\n>> This also should be made more clean.  Does it mean for example ability\n>> to tell which files have changed, or ability to diff working copy to\n>> either last comitted changes, or to any revision available in repository?\n>\n> Also, ability to diff one or more specified files in the working copy to\n> some specified revision.\n>\n>> scm>     <section id=\"technical_status\">\n>> scm>         <title>Technical Status</title>\n>> scm>         <section id=\"documentation\">\n>> scm>             <title>Documentation</title>\n>> scm>             <expl>\n>> scm>                 How well is the system documented? How easy is it to\n>> scm>                 get started using it?\n>> scm>             </expl>\n>> scm>             <compare>\n>> scm>                 <s id=\"git\">\n>> scm>                     Medium. The short help is too terse and obscure.\n>> scm>                     The man pages are extensive, but tend to be confusing.\n>> scm>                     The are many tutorials.\n>> scm>                 </s>\n>> scm>             </compare>\n>> scm>         </section>\n>>\n>> That of course depends on your opinion.  I would say \"Good\", now that\n>> there is \"Git User's Manual\" distributed with Git, and now that there\n>> started semi-official \"Git Community Book\" (http://book.git-scm.com).\n>\n> Interesting that versioncontrolblog, which, if I am not mistaken, is\n> Alexey's site, states for Git Documentation:\n>\n> | Good. There is extensive documentation for every command, and many\n> | tutorials.\n>\n> http://www.versioncontrolblog.com/comparison/Git/index.html\n>\n> So, I am not sure were the word \"Medium\" came from.\n>\n>\n> Dmitry\n>\n\n\n\n-- \nАлексей Махоткин\nhttp://squadette.ru/\n"},{"id":"90681","messageId":"200809141948.07160.jnareb@gmail.com","threadId":"15518","inReplyTo":"20080914144306.GF28210@dpotapov.dyndns.org","subject":"Re: Git at Better SCM Initiative comparison of VCS (long)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-09-14T17:48:05Z","receivedAt":"2008-09-14T17:48:05Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Sun, 14 Sep 2008, Dmitry Potapov wrote:\n> \n> I have added Alexey Mahotkin in CC, who is allegedly the author of that\n> information about Git that you can read on the better-scm site.\n\nDid you forwarded him my original email, I should I do it?\n\n\nI'm sorry about that, I should have tried to find original author\nof Git entry on Better SCM Initiative comparison table, and CC him.\nAs excuse I have the fact that while instructions how to add new\nSCM to the table are easy to find and quite detailed, this is not\nthe case for trying to correct information in it, including how to\nfind original authors.\n\nBy the way, perhaps I haven't stressed this like I should, but the\nmost important thing I wanted to ask git list about, besides insight\nin my comments and proposal for changes, was if it is possible\nusing current hooks infrastructure to restrict changes coming from\nsome account in such a way as to allow it only if all changes are\nrestricted to specified directory.  In short if \"Repository Permissions\"\n_can_ be implemented on per-directory and/or per-file basis (never\nmind the fact that it is better to use social means rather than\ntechnical restrictions, and distributed SCM are good at social solution\nof a 'honors system').\n\n\n> On Sat, Sep 13, 2008 at 07:06:16PM +0200, Jakub Narebski wrote:\n> > \n> > I have thought about trying yet another time... but Git was already\n> > added; see http://better-scm.berlios.de/news/changes-2008-08-07/\n> \n> Interesting, the site still mentions Git as missing in a few places.\n> For instance, when you click on Git in the list of alternatives, you\n> get this: http://better-scm.berlios.de/alternatives/git/\n> and then when you got to FAQ, you can read this:\n> \n> | The reason it's not there is that while many people have complained\n> | about its absense, no one suitable has volunteered to become its\n> | champion and supplied a good enough patch. [...]\n\nWell, I have also noticed that, and I have planned on mentioning this\ndiscrepancy when sending corrections for Git for SCM comparison table\nto Shlomi Fish / Better SCM Initiative.\n\n> | In addition to everything that was said here, it seems that the\n> | originator and maintainer of the site and comparison is now banned\n> | from sending messages to vger.kernel.org, which hosts several\n> | Linux-kernel-related mailing-lists, including the git one. This has\n> | interfered with some of his Linux-related open-source work, including\n> | trying to find a \"Better SCM\" maintainer for git. This is unfortunate,\n> | but changing this situation, is currently beyond his control.\n> \n> Source: http://better-scm.berlios.de/faq/#git-missing\n> \n> I am surprised to hear that Shlomi Fish is banned...\n\nWell, anti-SPAM filter at vger.kernel.org is rather heavy handed; it\nstopped a few legitimate posts of mine, and even a few patches.\nHowever admins are responsive and reasonable, so I wonder why Shlomi\nFish couldn't solve this issue.\n\nI wonder if it is perhaps a case of strange email headers, or\nsomething...\n\n> > scm>     <section id=\"repos_operations\">\n> > scm>         <title>Repository Operations</title>\n> > scm>         <section id=\"atomic_commits\">\n> > scm>             <title>Atomic Commits</title>\n> > scm>             <expl>\n> > scm>                 Support for atomic commits means that if an\n> > scm>                 operation on the repository is interrupted\n> > scm>                 in the middle, the repository will not be\n> > scm>                 left in an inconsistent state. Are the\n> > scm>                 check-in operations atomic, or can\n> > scm>                 interrupting an operation leave the\n> > scm>                 repository in an intermediate state?\n> > scm>             </expl>\n> > \n> > Here I think the explanation of a criterion (feature) is clear enough.\n> > I might have added that \"interruption\" include killing of a process\n> > during for example commit, lack of disk space for a full commit, or\n> > a network fail during network operation (fetch or push, or equivalent).\n> \n> My initial reaction was to say that killing a process with -9 is not\n> what you expect to see in practice, but a second later, I realized how\n> wrong I was. Lack of memory may cause that the process gets killed with\n> -9, and it has been observed in practice (at least, in case of Mercurial\n> repo): http://norman.walsh.name/2007/08/09/mercurial\n\nWell, kill -9 might be not very common, but interrupting for example\nfetch process which looks to take too long, or some operation that you\nfound shouldn't be run, with ^C is I think more common.\n\n> Another thing that is not clear in the above criterion is what exactly\n> \"inconsistent state\" (or \"intermediate state\") means. For instance, if\n> Git gets killed during commit, you may have to remove .git/index.lock\n> manually. AFAIK, Mercury leaves the 'journal' file and you have to\n> run \"hg recovery\". Does it mean that the commit is not atomic?\n\nIMHO \"atomic commits\" (or rather \"atomic operations\", see below) is\nabout commit being either in full, or not done at all.  The fact\nthat SCM might need some manual steps to recover from failure shouldn't\nfactor in evaluating this criterion.\n\n> Another thing here is that \"git commit\" is local, so I am not sure\n> if this question includes network operations...\n\nWell, I think this session would be better titled \"Atomic Operations\"\nor just \"Atomicity\".  Although I'm not sure if for example in Git\nall operations are atomic under all conditions...\n\nBut even if we leave it \"Atomic Commits\", as for centralized SCM\ncommit includes network operation, to have centralized and distributed\nSCM on equal footing, for distributed SCM this in my opinion should\nmean both atomic commit, and atomic push.  (And that should be stated\nexplicitly in the description...)\n\n> > scm>         <section id=\"move\">\n> > scm>             <title>Files and Directories Moves or Renames</title>\n> > scm>             <expl>\n> > scm>                 Does the system support moving a file or directory to\n> > scm>                 a different location while still retaining the history\n> > scm>                 of the file? <b>Note:</b> also see the next section\n> > scm>                 about intelligent merging of renamed paths.\n> > scm>             </expl>\n> > \n> > In my opinion this criterion is next to worthess without more in depth\n> > clarification of what does it mean to \"support\" moves or renames; as\n> > entries for different systems are written by different people, if it\n> > is not clear how to check if some feature is supported, some might\n> > write 'no' for some system A, and some other person can write 'yes'\n> > for other system B, even if the support is better in system A than in\n> > system B (and would be considered enough, i.e. 'yes' answer, by the\n> > creator of this criterion).\n> > \n> > For me the support for renames/moves and copying (see next section)\n> > means that:\n> > \n> >  0.) When examining or going to some point in the history (some old\n> >      revision/version of a project) the state you get is _exactly_\n> >      the same as it was at that time, exactly the same as it was\n> >      recorded (comitted) then.\n> > \n> >      For example tricks with moving *,v files in the CVS repository\n> >      break this assertion.\n> \n> IMHO, the above assertion is assumed when we talk about renaming, as\n> the system that is not capable of that will not be qualified as an\n> SCM. Yet, there is still plenty way to interpret the above criterion.\n> Even in CVS, the history of the file does not disappear when you move\n> a file. You can just write, this file move was renamed from old-name,\n> so anyone can get old history without any problem. Of course, it will\n> require some an additional step taken manually. But if the requirement\n> is to see all log history with one $scm log command, you can just copy\n> old log into log of a newly added file. Of course, you cannot run $scm\n> annotate on that file and see who changed what line, but there is no\n> such a requirement above.\n\nI have written this obvious requirement (that it is \"obvious\" can be\nseen in the fact that it got number '0' -- zero -- and not '1'; but\nperhaps it was too subtle) to exclude CVS \"support\" for renames by\ncopying *,v file to new name, as after this operation if you would\ncheckout old revision you would get extra file, the new name one.\nSo this 'solution' wouldn't satisfy this requirement.\n\n> So, I agree, it should be better defined.\n\nNice to be in agreement.\n\nIt would be best if there was some automated test for each criterion,\nor at least description how to check if SCM fulfils it; not necessary\nvisible in the table by default.\n\n> >  1.) When examining history of a project as a whole version control\n> >      system tells you that file was renamed (moved). I would consider\n> >      having there renaming represented as copy + delete to be only\n> >      a partial support of this feature.\n> \n> If files moving is interpreted in the sense of preserving the old history\n> then copy + delete fully satisfies that criterion.\n> \n> However, if you defined support of file movement as ability to see that\n> some file when you look at the history of the whole project then\n> certainly copy + delete representation would not satisfy it.\n\nWell, I would consider 'copy + delete' as \"good enough\" solution; not\nperfect, but enough for most cases.\n\n> So, perhaps, it should be two separate points:\n> - ability to preserve history of rename (with detail clarification\n>   of what it means)\n> - ability to show renames in the project history\n\nThat are points '1' and '2' on my list, perhaps stated bit differently:\nshowing renames in full history / history of project as whole, and\nfollowing history of a single file across renames.\n \n> > scm>                 <s id=\"git\">\n> > scm>                     Renames are supported for most practical\n> > scm>                     purposes.  Git even detects renames when a file has been\n> > scm>                     changed afterward the rename.  However, due to a peculiar\n> > scm>                     repository structure, renames are not recorded\n> > scm>                     explicitly, and Git has to deduce them (which works well\n> > scm>                     in practice).\n> > scm>                 </s>\n[...]\n \n> > Second, we can think about how the above statement could be improved.\n> > \n> \n> <long and detail explanation of how git works>\n> \n> > \n> > ...Now only put the above in a few short sentences to be used in\n> > \"Better SCM Initiative\" comparison table...\n> \n> Git tracks content rather than file-ids, and therefore it uses heuristics\n> for rename detection.  This approach has an advantage of being able to\n> preserve history for code lines between files, which usually happens much\n> more often than file renaming.\n\nI would rather write\n\n  Renames are supported for most practical purposes[1]. By design Git\n  does heuristic <i>rename detection</i> (based on similarity score of\n  pathnames and file contents), instead of doing rename tracking (which\n  usually is based on some kind of file-ids).  This approach allows for\n  more generic content tracking of code movement (which usually happens\n  much often than wholesame file renaming), e.g. in \"git blame -C -C\".\n\n  Footnotes:\n  [1] \"git log --follow <i>filename</i>\" works only for very simple\n      history currently; rename detection gets confused by empty files\n      and files consisting mainly of boilerplate (e.g. license text).\n\nBut this also could be I think improved.\n\n\nBTW. I wouldn't mention problem with 'new files in renamed directories',\nwhich is IMHO separate issue, and contrary to what Mark Shuttleworth\nwrote in \"Renaming is the killer app of distributed version control\"\n(http://www.markshuttleworth.com/archives/123) that part of rename\nsupport is not that important.  Especially that I doubt that it was\ntested / checked for other SCM in the table.\n\n> > scm>                 <s id=\"git\">\n> > scm>                     No. As detailed in the <a\n> > scm>                         href=\"http://git.or.cz/gitwiki/GitFaq#rename-tracking\">Git\n> > scm>                         FAQ</a>:\n> > scm>                     \"Git has a rename command git mv, but that is just a\n> > scm>                     convenience. The effect is indistinguishable from removing\n> > scm>                     the file and adding another with different name and the\n> > scm>                     same content.\"\n> > scm>                 </s>\n> > \n> > This is of course NOT TRUE.  If the author bother checking (which\n> > would be helped if there was available simple shell script, or simple\n> > Perl script, testing 'intelligent_renames' criterion) he/she would\n> > notice that git does apply change to renamed file, both if file\n> > itself is renamed, and if directory it is in gets renamed.\n> \n> Sure. But it just demonstrates that the line of reasoning, which was\n> clearly based on unstated assumption of how file-id tracking performs\n> merge in this situation leads to the wrong conclusion for Git as it is\n> the content tracking system, so Git does that differently.\n\nWell, if you are not sure, test it.  I did this; admittedly you has\nto take care for your test files to have some more content to better\nresemble real-life examples for Git contents similarity based rename\ndetection to work.\n\nSide note: I _think_ that usually if rename detection fails, 3-way\nmerge would fail too, where by fail I mean the situation where it\nis hard to resolve textual conflict, not that there is conflict.\n\n> Perhaps, it would make sense to extend GitFaq to better cover that\n> point, because people with other SCM background could easily conclude\n> that Git cannot do \"intelligent merge\" after reading about git-mv.\n\nThat is a fact that the section in GitFaq about tracking renames\nhttp://git.or.cz/gitwiki/GitFaq#rename-tracking should be cleaned up\n(for example \"git annotate\" is now just a convenient shortcut to\n\"git blame -c\"; it is no longer alternate implementation), and perhaps\neven rewritten.  I think that the whole reasoning about rename tracking\nvs rename detection, perhaps with famous Linus Torvalds post on that\nmatter (if I can find it) should be put on separate page, as it will\nbe I think quite lenghty, while GitFaq should contain only bare-bones\nconsequences of such decision (and link to details).\n\n> > scm>         <section id=\"changesets\">\n> > scm>             <title>Changesets' Support</title>\n> > scm>             <expl>\n> > scm>                 Does the repository support changesets? Changesets are a way\n> > scm>                 to group a number of modifications that are relevant to each\n> > scm>                 other in one atomic package, that can be cancelled or \n> > scm>                 propagated as needed.\n> > scm>             </expl>\n> > \n> > Here it is not entirely clean what creator of \"Better SCM Initiative\"\n> > comparison table had on mind, what he meant by this.  Not all version\n> > control systems are changeset based; some are snapshot based.  I guess\n> > that for snapshot based SCM the above requirement is equivalent to\n> > \"Whole tree commits\".\n> \n> Yes, it is irrelevant to being changeset or snapshot based.\n\nErrr... what I meant to say that description is clearly inspired by\nchangeset based SCM, but the criterion is important also for snapshot\nbased; it is simply not without any doubts that it refers to the\nvisible UI feature, and not underlying repository design (engine).\n\n> It is whether modification to more than one file can be commited (and\n> propogated) atomically. I also suppose that those changes should be\n> shown in history as a single change (not many changes too different\n> files that took place in the same time and the same commit comment).\n> \n> However, the whole tree commit is a more strict requirement than\n> just being able to commit a group of changes atomically. For example,\n> \"svn ci\" creates a changeset and atomically store all its modification\n> on the server. Yet, it is not the whole tree commit, because the result\n> tree may differ from the tree that you commiting (files that are not\n> modified by changeset may differ).\n\nI think the gist of intent was to have revisions (revision identifiers)\nrefer to the state of a whole repository (or to changes to the set of\nfiles as a whole: a changeset).\n\nI agree that \"whole tree commit\" has slightly different semantics than\n\"supporting changesets\".\n\n> > scm>                 <s id=\"git\">\n> > scm>                     Yes, Changesets are supported, \n> > scm>                     and there's some flexibility in creating them.\n> > scm>                 </s>\n> > scm>            </compare>\n> > scm>         </section>\n> > \n> > [Again, Git part was re-wrapped for better readibility]\n> > \n> > In my opition, such an _empty_ addition (\"there's some flexibility in\n> > creating them\") is totally unnecessary; it adds no solid information\n> > (what does it mean \"some flexibility\") and should be removed.\n> \n> Agreed. I suspect the author implied by that Git allows to stage\n> and commit separately chunk without commiting the whole file.\n> Yet, as it is worded above, it is useless.\n\nHmmm... now that you stated that possibility I see how this wording can\nrefer to it.  Nevertheless it is irrelevant to the criterion discussed;\nalso Darcs which also has extra flexibility (chunk selection in\ninteractive git-add / git-commit were inspired by Darcs feature) doesn't\nhave any extra wording.\n\n> > scm>         <section id=\"tracking_uncommited_changes\">\n> > scm>             <title>Tracking Uncommited Changes</title>\n> > scm>             <expl>\n> > scm>                 Does the software have an ability to track the changes in the\n> > scm>                 working copy that were not yet committed to the repository?\n> > scm>             </expl>\n> > \n> > This also should be made more clean.  Does it mean for example ability\n> > to tell which files have changed, or ability to diff working copy to\n> > either last comitted changes, or to any revision available in repository?\n> \n> Also, ability to diff one or more specified files in the working copy to\n> some specified revision.\n\nRight.\n\nI'm not sure now if \"Tracking Uncommitted Changes\" is a good name for\nthis feature / criterion, but I don't have definite idea for change...\n\n> > scm>     <section id=\"technical_status\">\n> > scm>         <title>Technical Status</title>\n> > scm>         <section id=\"documentation\">\n> > scm>             <title>Documentation</title>\n> > scm>             <expl>\n> > scm>                 How well is the system documented? How easy is it to\n> > scm>                 get started using it?\n> > scm>             </expl>\n> > scm>             <compare>\n> > scm>                 <s id=\"git\">\n> > scm>                     Medium. The short help is too terse and obscure.\n> > scm>                     The man pages are extensive, but tend to be confusing.\n> > scm>                     The are many tutorials.\n> > scm>                 </s>\n> > scm>             </compare>\n> > scm>         </section>\n> > \n> > That of course depends on your opinion.  I would say \"Good\", now that\n> > there is \"Git User's Manual\" distributed with Git, and now that there\n> > started semi-official \"Git Community Book\" (http://book.git-scm.com).\n> \n> Interesting that versioncontrolblog, which, if I am not mistaken, is\n> Alexey's site, states for Git Documentation:\n> \n> | Good. There is extensive documentation for every command, and many\n> | tutorials.\n> \n> http://www.versioncontrolblog.com/comparison/Git/index.html\n> \n> So, I am not sure were the word \"Medium\" came from.\n\nBackward compatibility^W^W Old impressions die hard, I would guess...\nAnd the meme that git documentation is not user friendly is hard to\nfight.\n\n\nThank you very much for your comments.\n-- \nJakub Narebski\nPoland\n"},{"id":"90688","messageId":"20080914194802.GH28210@dpotapov.dyndns.org","threadId":"15518","inReplyTo":"200809141948.07160.jnareb@gmail.com","subject":"Re: Git at Better SCM Initiative comparison of VCS (long)","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2008-09-14T19:48:02Z","receivedAt":"2008-09-14T19:48:02Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Sun, Sep 14, 2008 at 07:48:05PM +0200, Jakub Narebski wrote:\n> \n> By the way, perhaps I haven't stressed this like I should, but the\n> most important thing I wanted to ask git list about, besides insight\n> in my comments and proposal for changes, was if it is possible\n> using current hooks infrastructure to restrict changes coming from\n> some account in such a way as to allow it only if all changes are\n> restricted to specified directory. \n\nI believe the update hook should be able to do that. You have oldrev and\nnewrev, so you can run \"git diff --name-only oldrev newrev\" and see what\nfiles are going to change. And then verify that the user has the write\naccess to this directories or files.\n\nI have not tried it yet, and I don't think we have a ready example of\nhow to do that, but I believe that the example of the update hook that\nrestricts user access based on the target branch can be used as a\nstarting point.\n\n> \n> IMHO \"atomic commits\" (or rather \"atomic operations\", see below) is\n> about commit being either in full, or not done at all.  The fact\n> that SCM might need some manual steps to recover from failure shouldn't\n> factor in evaluating this criterion.\n\nAgreed. Your wording makes much more sense than what was used in the\nabove criterion.\n\n> \n> > Another thing here is that \"git commit\" is local, so I am not sure\n> > if this question includes network operations...\n> \n> Well, I think this session would be better titled \"Atomic Operations\"\n> or just \"Atomicity\".  Although I'm not sure if for example in Git\n> all operations are atomic under all conditions...\n\nI believe that all git basic operations are atomic. In fact, you either\ngot a new revision with new SHA-1 or don't. Aborting operation may\nleave some dangling objects, but it is okay, because they will be\ngarbage collected later. But I am not sure about additional utilities\nsuch as git-svn. Git-svn uses rebase as it dcommits, being interrupted,\nit may leave you in some strange state. It is possible to recover but\nit may be not obvious for newbies. Other than that, I think everything\nis very resilient to any interruption.\n\n> \n> But even if we leave it \"Atomic Commits\", as for centralized SCM\n> commit includes network operation, to have centralized and distributed\n> SCM on equal footing, for distributed SCM this in my opinion should\n> mean both atomic commit, and atomic push.  (And that should be stated\n> explicitly in the description...)\n\nAgreed.\n\n> \n> > So, perhaps, it should be two separate points:\n> > - ability to preserve history of rename (with detail clarification\n> >   of what it means)\n> > - ability to show renames in the project history\n> \n> That are points '1' and '2' on my list, perhaps stated bit differently:\n> showing renames in full history / history of project as whole, and\n> following history of a single file across renames.\n\nI did not mean '1' and '2' as priorities, but that it is slightly\ndifferent features and both can be titled as support of renaming.\n\n> > \n> > Git tracks content rather than file-ids, and therefore it uses heuristics\n> > for rename detection.  This approach has an advantage of being able to\n> > preserve history for code lines between files, which usually happens much\n> > more often than file renaming.\n> \n> I would rather write\n> \n>   Renames are supported for most practical purposes[1]. By design Git\n>   does heuristic <i>rename detection</i> (based on similarity score of\n>   pathnames and file contents), instead of doing rename tracking (which\n>   usually is based on some kind of file-ids).  This approach allows for\n>   more generic content tracking of code movement (which usually happens\n>   much often than wholesame file renaming), e.g. in \"git blame -C -C\".\n\nSounds good to me. Perhaps, I would drop '(which usually... file-ids)'\nto make the sentence a bit shorter.\n\n> > It is whether modification to more than one file can be commited (and\n> > propogated) atomically. I also suppose that those changes should be\n> > shown in history as a single change (not many changes too different\n> > files that took place in the same time and the same commit comment).\n> > \n> > However, the whole tree commit is a more strict requirement than\n> > just being able to commit a group of changes atomically. For example,\n> > \"svn ci\" creates a changeset and atomically store all its modification\n> > on the server. Yet, it is not the whole tree commit, because the result\n> > tree may differ from the tree that you commiting (files that are not\n> > modified by changeset may differ).\n> \n> I think the gist of intent was to have revisions (revision identifiers)\n> refer to the state of a whole repository (or to changes to the set of\n> files as a whole: a changeset).\n\nPerhaps. Though, then SVN should have 'Yes', but it listed as \"partial\nsupport.\" It seems this feature also implies ability to create a\nchangset and propagate as separated steps. Yet, svk is listed \"Same as\nsubversion.\" So, I don't really know what this support of changesets\nreally means.\n\n> \n> Hmmm... now that you stated that possibility I see how this wording can\n> refer to it.  Nevertheless it is irrelevant to the criterion discussed;\n\nAgreed.\n\n> \n> > > scm>         <section id=\"tracking_uncommited_changes\">\n> > > scm>             <title>Tracking Uncommited Changes</title>\n> > > scm>             <expl>\n> > > scm>                 Does the software have an ability to track the changes in the\n> > > scm>                 working copy that were not yet committed to the repository?\n> > > scm>             </expl>\n> > > \n> > > This also should be made more clean.  Does it mean for example ability\n> > > to tell which files have changed, or ability to diff working copy to\n> > > either last comitted changes, or to any revision available in repository?\n> > \n> > Also, ability to diff one or more specified files in the working copy to\n> > some specified revision.\n> \n> Right.\n> \n> I'm not sure now if \"Tracking Uncommitted Changes\" is a good name for\n> this feature / criterion, but I don't have definite idea for change...\n\nActually, I don't like this name either. In particular, the word\n\"tracking\". Perhaps, \"Showing Uncommitted Changes\" would be a better\nname. Yet, ability to show diff between the working copy as some\narbitrary version should be listed as a separate feature.\n\n> > So, I am not sure were the word \"Medium\" came from.\n> \n> Backward compatibility^W^W Old impressions die hard, I would guess...\n> And the meme that git documentation is not user friendly is hard to\n> fight.\n\nYes. And, frankly, earlier versions of it were not very user friendly.\nWhen you looked at some porcelain command and it referred you to\nplumbing to see what options it takes, that gave very bad impression.\nNow, this and similar shortcomings are corrected, but as you said the\nold impressions die hard...\n\n\nDmitry\n"},{"id":"90693","messageId":"20080914210648.GB26608@spearce.org","threadId":"15518","inReplyTo":"20080914194802.GH28210@dpotapov.dyndns.org","subject":"Re: Git at Better SCM Initiative comparison of VCS (long)","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-09-14T21:06:48Z","receivedAt":"2008-09-14T21:06:48Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Dmitry Potapov <dpotapov@gmail.com> wrote:\n> On Sun, Sep 14, 2008 at 07:48:05PM +0200, Jakub Narebski wrote:\n> > \n> > [...] if it is possible\n> > using current hooks infrastructure to restrict changes coming from\n> > some account in such a way as to allow it only if all changes are\n> > restricted to specified directory. \n> \n> I believe the update hook should be able to do that. You have oldrev and\n> newrev, so you can run \"git diff --name-only oldrev newrev\" and see what\n> files are going to change. And then verify that the user has the write\n> access to this directories or files.\n> \n> I have not tried it yet, and I don't think we have a ready example of\n> how to do that, but I believe that the example of the update hook that\n> restricts user access based on the target branch can be used as a\n> starting point.\n\ncontrib/hooks/update-paranoid can do both branch and file path\nlevel restrictions.  I used it at my prior day-job to prevent some\naccidental changes from folks who didn't usually need to modify\ncertain parts of the repository.\n\n-- \nShawn.\n"},{"id":"90700","messageId":"200809142329.03186.jnareb@gmail.com","threadId":"15518","inReplyTo":"20080914210648.GB26608@spearce.org","subject":"Re: Git at Better SCM Initiative comparison of VCS (long)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-09-14T21:29:01Z","receivedAt":"2008-09-14T21:29:01Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Sun, 14 Sep 2008, Shawn O. Pearce wrote:\n> Dmitry Potapov <dpotapov@gmail.com> wrote:\n>> On Sun, Sep 14, 2008 at 07:48:05PM +0200, Jakub Narebski wrote:\n>>> \n>>> [...] if it is possible\n>>> using current hooks infrastructure to restrict changes coming from\n>>> some account in such a way as to allow it only if all changes are\n>>> restricted to specified directory. \n>> \n>> I believe the update hook should be able to do that. You have oldrev and\n>> newrev, so you can run \"git diff --name-only oldrev newrev\" and see what\n>> files are going to change. And then verify that the user has the write\n>> access to this directories or files.\n>> \n>> I have not tried it yet, and I don't think we have a ready example of\n>> how to do that, but I believe that the example of the update hook that\n>> restricts user access based on the target branch can be used as a\n>> starting point.\n> \n> contrib/hooks/update-paranoid can do both branch and file path\n> level restrictions.  I used it at my prior day-job to prevent some\n> accidental changes from folks who didn't usually need to modify\n> certain parts of the repository.\n\nCould you then update contrib/hooks/update-paranoid documentation?\nIt talks only about branch level restrictions (created, delete, \nfast-forward, forced update for a given ref class).\n\nThanks in advance\n-- \nJakub Narebski\nPoland\n"},{"id":"90701","messageId":"200809150237.48460.jnareb@gmail.com","threadId":"15518","inReplyTo":"20080914194802.GH28210@dpotapov.dyndns.org","subject":"Re: Git at Better SCM Initiative comparison of VCS (long)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-09-15T00:37:47Z","receivedAt":"2008-09-15T00:37:47Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Sun, 14 Sep 2008, Dmitry Potapov wrote:\n> On Sun, Sep 14, 2008 at 07:48:05PM +0200, Jakub Narebski wrote:\n\n> > > Another thing here is that \"git commit\" is local, so I am not sure\n> > > if this question includes network operations...\n> > \n> > Well, I think this session would be better titled \"Atomic Operations\"\n> > or just \"Atomicity\".  Although I'm not sure if for example in Git\n> > all operations are atomic under all conditions...\n> \n> I believe that all git basic operations are atomic. In fact, you either\n> got a new revision with new SHA-1 or don't. Aborting operation may\n> leave some dangling objects, but it is okay, because they will be\n> garbage collected later. But I am not sure about additional utilities\n> such as git-svn. Git-svn uses rebase as it dcommits, being interrupted,\n> it may leave you in some strange state. It is possible to recover but\n> it may be not obvious for newbies. Other than that, I think everything\n> is very resilient to any interruption.\n\nI was thinking here about long-lasting and multiple-parts operations\nlike for example git-clone.  Nevertheless we would never be in\ninconsistent state.\n \n> > > So, perhaps, it should be two separate points:\n> > > - ability to preserve history of rename (with detail clarification\n> > >   of what it means)\n> > > - ability to show renames in the project history\n> > \n> > That are points '1' and '2' on my list, perhaps stated bit differently:\n> > showing renames in full history / history of project as whole, and\n> > following history of a single file across renames.\n> \n> I did not mean '1' and '2' as priorities, but that it is slightly\n> different features and both can be titled as support of renaming.\n\nI didn't mean '1' and '2' as priorities; they are more or less equal,\nalthough I would say that '1' might be prerequisite to '2'.  '0' is\nhowever a base which must be satisfied for tool to be named to have\n\"rename support\".\n \n> > > \n> > > Git tracks content rather than file-ids, and therefore it uses heuristics\n> > > for rename detection.  This approach has an advantage of being able to\n> > > preserve history for code lines between files, which usually happens much\n> > > more often than file renaming.\n> > \n> > I would rather write\n> > \n> >   Renames are supported for most practical purposes[1]. By design Git\n> >   does heuristic <i>rename detection</i> (based on similarity score of\n> >   pathnames and file contents), instead of doing rename tracking (which\n> >   usually is based on some kind of file-ids).  This approach allows for\n> >   more generic content tracking of code movement (which usually happens\n> >   much often than wholesame file renaming), e.g. in \"git blame -C -C\".\n> \n> Sounds good to me. Perhaps, I would drop '(which usually... file-ids)'\n> to make the sentence a bit shorter.\n\nO.K.\n\n(But I would wait a bit for final proposal, with sending patch for\nscm-comparison.xml to Alexey and Shlomi.)\n\n> > > > scm>         <section id=\"tracking_uncommited_changes\">\n> > > > scm>             <title>Tracking Uncommited Changes</title>\n> > > > scm>             <expl>\n> > > > scm>                 Does the software have an ability to track the changes in the\n> > > > scm>                 working copy that were not yet committed to the repository?\n> > > > scm>             </expl>\n> > > > \n> > > > This also should be made more clean.  Does it mean for example ability\n> > > > to tell which files have changed, or ability to diff working copy to\n> > > > either last comitted changes, or to any revision available in repository?\n> > > \n> > > Also, ability to diff one or more specified files in the working copy to\n> > > some specified revision.\n> > \n> > Right.\n> > \n> > I'm not sure now if \"Tracking Uncommitted Changes\" is a good name for\n> > this feature / criterion, but I don't have definite idea for change...\n> \n> Actually, I don't like this name either. In particular, the word\n> \"tracking\". Perhaps, \"Showing Uncommitted Changes\" would be a better\n> name. Yet, ability to show diff between the working copy as some\n> arbitrary version should be listed as a separate feature.\n\nI don't have good name either. It is <something> about Uncommitted Changes.\nDealing with, or support for, or something...\n \n-- \nJakub Narebski\nPoland\n"},{"id":"92080","messageId":"200810012045.14276.jnareb@gmail.com","threadId":"15518","inReplyTo":"200809131906.18746.jnareb@gmail.com","subject":"Git at Better SCM Initiative comparison of VCS (long)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-10-01T18:45:13Z","receivedAt":"2008-10-01T18:45:13Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"I think that the information about Git at Better SCM Initiative\ncomparison of various version control systems\n\n  http://better-scm.berlios.de/comparison/comparison.html\n\nused also for versioncontrolblog \"Version control systems comparison\"\n\n  http://versioncontrolblog.com/comparison\n\nneeds a few corrections.\n\n\nTherefore below you can find proposed changes, as discussed here on\nthis mailing list (this time CC-ing author of Git entry, Alexey\nMahotkin of versioncontrolblog).  For each section (each compared\nfeature) I have put description, entry for one or more open source\ndistributed version control systems (for reference) and current entry\nfor Git, in email-quote like format (prefixed with \"scm> \"), then\nproposed corrected entry (if it needs correction) and some comments\nabout it.\n\nContrary to previous post in this thread I did not comment this time\non the comparison itself, for example not well defined criteria, and\nlack of tests or functional/use case description which would help to\ncheck if SCM supports given feature.\n\nI think this could be basis for Alexey to send corrections to\nBetter SCM comparison table.\n\nPlease comment\n\nscm>         <timestamp>\nscm>             $Id: scm-comparison.xml 322 2008-08-09 05:47:26Z shlomif $\nscm>         </timestamp>\n\nHere just so you know on which version it is based on.\n\nscm>     <section id=\"repos_operations\">\nscm>         <title>Repository Operations</title>\nscm>         <section id=\"atomic_commits\">\nscm>             <title>Atomic Commits</title>\nscm>             <expl>\nscm>                 Support for atomic commits means that if an\nscm>                 operation on the repository is interrupted\nscm>                 in the middle, the repository will not be\nscm>                 left in an inconsistent state. Are the\nscm>                 check-in operations atomic, or can\nscm>                 interrupting an operation leave the\nscm>                 repository in an intermediate state?\nscm>             </expl>\nscm>             <compare>\nscm>                 <s id=\"cvs\">No. CVS commits are not atomic.</s>\nscm>                 <s id=\"bazaar\">Yes. Commits are atomic.</s>\nscm>                 <s id=\"mercurial\">Yes.</s>\nscm>                 <s id=\"git\">Yes. Commits are atomic.</s>\nscm>             </compare>\nscm>         </section>\n\nNo comment here (beside the fact that table neds some unification, but\nthis is hardly the case for Better SCM comparison Git entry maintainer).\n\nscm>         <section id=\"move\">\nscm>             <title>Files and Directories Moves or Renames</title>\nscm>             <expl>\nscm>                 Does the system support moving a file or directory to\nscm>                 a different location while still retaining the history\nscm>                 of the file? <b>Note:</b> also see the next section\nscm>                 about intelligent merging of renamed paths.\nscm>             </expl>\nscm>             <compare>\nscm>                 <s id=\"bazaar\">Yes. Renames are supported for files and directories.</s>\nscm>                 <s id=\"mercurial\">Yes. Renames are supported.</s>\nscm>                 <s id=\"git\">\nscm>                     Renames are supported for most practical\nscm>                     purposes.  Git even detects renames when a file has been\nscm>                     changed afterward the rename.  However, due to a peculiar\nscm>                     repository structure, renames are not recorded\nscm>                     explicitly, and Git has to deduce them (which works well\nscm>                     in practice).\nscm>                 </s>\nscm>            </compare>\nscm>         </section>\n\nI would propose to change it to something like the followig:\n\n  Renames are supported for most practical purposes[1]. By design Git\n  does heuristic <i>rename detection</i> (based on similarity score of\n  pathnames and file contents), instead of doing rename tracking.  This\n  approach allows for more generic content tracking of code movement\n  (which usually happens much often than wholesame file renaming),\n  e.g. in \"git blame -C -C\".\n\n  Footnotes:\n  [1] \"git log --follow <i>filename</i>\" works only for very simple\n      history currently; rename detection can get confused by empty files\n      and files consisting mainly of boilerplate (e.g. license text).\n\nComments:\n\nI am a bit unsure about need for footnote.  Perhaps it should be simply\nremoved.  Also, perhaps instead of \"Renames are supported...\" it should\nbe \"File renames are supported...\", although it looks like it would\nimprove soon: see thread on git mailing list about detecting wholesale\nfirectory renames (with ability to track directory splitting, like now\ngit is able to track contents movement across files).\n\nscm>         <section id=\"intelligent_renames\">\nscm>             <title>Intelligent Merging after Moves or Renames</title>\nscm>             <expl>\nscm>                 If the system keeps tracks of renames, does it support\nscm>                 intelligent merging of the files in the history after\nscm>                 the rename? (For example, changing a file in a renamed\nscm>                 directory, and trying to merge it).\nscm>             </expl>\nscm>             <compare>\nscm>                 <s id=\"bazaar\">Yes. Renames are intelligent.</s>\nscm>                 <s id=\"mercurial\">\nscm>                     No. <a \nscm>                         href=\"http://hgbook.red-bean.com/hgbookch5.html#x9-1030005.4\">the\nscm>                         Mercurial book says:</a>\nscm>                     \"When you use the 'hg rename' command, Mercurial makes a \nscm>                     copy of each source file, then deletes it and marks the\nscm>                     file as removed. \"\nscm>                 </s>\nscm>                 <s id=\"git\">\nscm>                     No. As detailed in the <a\nscm>                         href=\"http://git.or.cz/gitwiki/GitFaq#rename-tracking\">Git\nscm>                         FAQ</a>:\nscm>                     \"Git has a rename command git mv, but that is just a\nscm>                     convenience. The effect is indistinguishable from removing\nscm>                     the file and adding another with different name and the\nscm>                     same content.\"\nscm>                 </s>\nscm>            </compare>\nscm>         </section>\n\nThis entry is incorrect[1]; it has to be changed to something like the\nfollowing proposal:\n\n  Yes, Git can deal with renamed files during merging, thanks to rename\n  detection.\n\nComments:\n\nGit does apply change to renamed file, both if file itself is renamed,\nand if directory it is in gets renamed (like in example in feature\ndescription).  What Git _currently_ doesn't support (at least for now,\nwith lack of detection of directories as a whole; this might change\nsoon) is with adding new files to the renamed directory: if one side\nrenamed directory and second side added new files in the old directory,\nthose new files would show at old name, not at new name.\n\nThere also might be two kinds of problems: first, if you are merging\nold and/or much diverged branch rename detection can use much of CPU\npower even if there are no renames present (this happened once or\ntwice).  Second, if similarity based rename detection fail you would\nnot get conflict and will be left with two versions of a file in\nworking directory; this might happen for example if you renamed some\n'sensitive' binary file (so small change results in large change in\nrepresentation) or change is too large compared to whole contents of \na file.  In second case it is expected that requested from time to time\nadvisory rename tracking would help.\n\nHmmm... I wonder if the above problems with rename detection happen\nmore often than problems with, usually file-id based, rename tracking\nused by other SCM.\n\nFootnote:\n=========\n[1] It looks like we really need http://git.or.cz/gitwiki/FileRenames\n\n\nBTW. I wonder if Mercurial entry isn't incorrect either...\n\nscm>         <section id=\"copy\">\nscm>             <title>File and Directories Copies</title>\nscm>             <expl>\nscm>                 Does the version control system support copying\nscm>                 files or directories to a different location at the\nscm>                 repository level, while retaining the history?\nscm>             </expl>\nscm>             <compare>\nscm>                 <s id=\"bazaar\">No. Copies are not supported.</s>\nscm>                 <s id=\"mercurial\">Yes. Copies are supported</s>\nscm>                 <s id=\"git\">No.  Copies are not supported.</s>\nscm>            </compare>\nscm>         </section>\n\nI would write that:\n\n  Copies detection is supported, but for performance reasons it is not\n  enabled by default.\n\nComments:\n\nPerhaps we could mention here that there are two thresholds of copying\ndetection: checking only changed files and --detect-copies-harder. Also\nworth of note might be the fact that git-blame has support for\ndetecting code copying, also across filenames.\n\nscm>         <section id=\"repos_clone\">\nscm>             <title>Remote Repository Replication</title>\nscm>             <expl>\nscm>                 Does the system support cloning a remote repository to get\nscm>                 a functionally equivalent copy in the local system? That \nscm>                 should be done without any special access to the remote \nscm>                 server except for normal repository access.\nscm>             </expl>\nscm>             <compare>\nscm>                 <s id=\"mercurial\">Yes.</s>\nscm>                 <s id=\"git\">Yes.  This is very intrinsic feature of Git.</s>\nscm>             </compare>\nscm>         </section>\n\nIn fact this is 'very intrinsic feature' of each distributed SCM...\nIn short: I think that simple 'Yes.' answer for Git would be better.\n\nscm>         <section id=\"push\">\nscm>             <title>Propagating Changes to Parent Repositories</title>\nscm>             <expl>\nscm>                 Can the system propagate changes from one repository to \nscm>                 another?\nscm>             </expl>\nscm>             <compare>\nscm>                 <s id=\"mercurial\">Yes.</s>\nscm>                 <s id=\"git\">Yes.  (The Linux kernel development process uses this extremely often).</s>\nscm>             </compare>\nscm>         </section>\n\nAgain I think that simple \"Yes\" would be sufficient.  The sentence in\nparentheses doesn't bring any new information, so IMHO should be\nremoved.  Especially that Linux kernel uses also patch based wokflow \nvery extensively.\n\nscm>         <section id=\"permissions\">\nscm>             <title>Repository Permissions</title>\nscm>             <expl>\nscm>                 Is it possible to define permissions on access to different\nscm>                 parts of a remote repository? Or is access open for all? \nscm>             </expl>\nscm>             <compare>\nscm>                 <s id=\"bazaar\">\nscm>                     Basic access control can be implemented through a\nscm>                     contributed hook script.  ACL support for the\nscm>                     Bazaar server is planned.\nscm>                 </s>\nscm>                 <s id=\"mercurial\">\nscm>                     Yes. It is possible to lock down repositories,\nscm>                     subdirectories, or files using hooks.\nscm>                 </s>\nscm>                 <s id=\"git\">\nscm>                     No, but a single server can serve many repositories.\nscm>                     Also, UNIX permissions can be used to some extent.\nscm>                 </s>\n\nLine-wrapped for better readibility.\n\nscm>             </compare>\nscm>         </section>\n\nI think the answer should be here:\n\n  Yes. It is possible to lock down repositories, branches, \n  subdirectories, or files using hooks (see for example\n  <a href=\"\">contrib/hooks/paranoid</a> example hook).\n\nComments:\n\nShawn, could you _please_ make documentation of 'paranoid' contrib hook\ncomplete by documenting how to configure it to lock down directories\nor files?\n\nAs the feature seems to be more about fine-grained access control \n(by the way something that Karl Fogel in his \"Prodicting OSS...\" book\nis against, as better solved by socual and not technological means)\nI have not mentioned here things like web server permissions for WebDAV\naccess, UNIX file permissions, or tools like Gitosis or ssh_acl, which\nare about access to repository as a whole.\n\nscm>         <section id=\"changesets\">\nscm>             <title>Changesets' Support</title>\nscm>             <expl>\nscm>                 Does the repository support changesets? Changesets are a way\nscm>                 to group a number of modifications that are relevant to each\nscm>                 other in one atomic package, that can be cancelled or \nscm>                 propagated as needed.\nscm>             </expl>\nscm>             <compare>\nscm>                 <s id=\"darcs\">\nscm>                     Yes. Changesets are supported.\nscm>                 </s>\nscm>                 <s id=\"mercurial\">\nscm>                     Yes. Changesets are supported.\nscm>                 </s>\nscm>                 <s id=\"git\">\nscm>                     Yes, Changesets are supported,\nscm>                     and there's some flexibility in creating them.\nscm>                 </s>\n\nLine wrapped for better eradibility.\n\nscm>            </compare>\nscm>         </section>\n\nIn my opition, such an _empty_ addition (\"there's some flexibility in\ncreating them\") is totally unnecessary; it adds no solid information\n(what does it mean \"some flexibility\") and should be removed.\n\nI think the entry should simply state \"Yes. Changesets are supported.\";\nsee for example entry for Darcs (from which Iu the idea of having\n\"git add --interactive\" was taken from).\n\nComments:\n\nDescription of this feature is not entirely clean, but I think\neverybody knows what it meant to mean.\n\nscm>         <section id=\"annotate\">\nscm>             <title>Tracking Line-wise File History</title>\nscm>             <expl>\nscm>                 Does the version control system have an option to track the\nscm>                 history of the file line-by-line? I.e., can it show for each line\nscm>                 at which revision it was most recently changed, and by whom?\nscm>             </expl>\nscm>             <compare>\nscm>                 <s id=\"mercurial\">Yes. (hg annotate)</s>\nscm>                 <s id=\"git\">Yes. (git blame).</s>\nscm>            </compare>\nscm>         </section>\nscm>     </section>\n\nThis is O.K, but I wonder if it wouldn't be worth to add information\nabout unique (as far as I know) git-blame abilities, something like:\n\n  Yes.  (git blame).\n\n  <a href=\"\">git-blame</a> can be asked to detect moving lines in file\n  and between files; there exist GUI for blame (\"git gui blame <file>\").\n\nComments:\n\nOne would suspect that because Git is based towards whole project\nhistory, and not per file history, git-blame is slow.  To migitate\nthat there is incremental blame mode used to reduce latency in graphical\nblame viewers like \"git gui blame\", contrib/blameview, or the one\nin QGit.\n\nBut anegdotical evidence (meaning in this case discussion with Pieter\nde Bie of vcscompare blog on #git IRC channel) shows that git-blame\nis of similar performance that its equivalent in Mercurial and Bazaar.\n(It is hard to compare with \"cvs annotate\" as for centralized SCM there\nis matter of network speed; I don't know how it compares for local\naccess, i.e. repository and file/client on the same filesystem).\n\nscm>     <section id=\"features\">\nscm>         <title>Features</title>\nscm>         <section id=\"work_on_dir\">\nscm>             <title>Ability to Work only on One Directory of the Repository</title>\nscm>             <expl>\nscm>                 Can the version control system checkout only one directory of\nscm>                 the repository? Or restrict the check-ins to only one \nscm>                 directory?\nscm>             </expl>\nscm>             <compare>\nscm>                 <s id=\"bazaar\">For checkouts: No. For checkins: Yes.</s>\nscm>                 <s id=\"mercurial\">\nscm>                     It is possible to commit changes only in a subset of the\nscm>                     tree. There are plans for partial checkouts.\nscm>                 </s>\nscm>                 <s id=\"git\">\nscm>                     No.  However, commits could be restricted somewhat,\nscm>                     see the \"Repository Permissions\".\nscm>                 </s>\n\nAgain, re-wrapped for better readibility.\n\nscm>            </compare>\nscm>         </section>\n\nI'm not sure if the entry for Git shouldn't read as:\n\n  No. All changes are made repository-wide.\n\nas in for Aegis.  On the other hand it is possible to restrict commits\nand remote access to only some subset of the tree using hooks; also\nthere is work done on implementing partial/sparse checkout for Git by\nNguyễn Thái Ngọc Duy (pclouds).  So perhaps it should read instead,\nsimilarly to what we have for Mercurial:\n\n  It is possible to restrict commit via hooks to changes only in\n  a subset of the tree. Implementing partial/sparse checkouts is\n  work in progress.\n\nComments:\n\nAgain, as said in \"Producting OSS...\" it is better to implement such\nrestrictions using social rather that technical means; at least for\ncheckins; there are some reasons (disk space, protecting against\naccidental changes, <insert your reason here>) for partial checkouts.\n\nscm>         <section id=\"tracking_uncommited_changes\">\nscm>             <title>Tracking Uncommited Changes</title>\nscm>             <expl>\nscm>                 Does the software have an ability to track the changes in the\nscm>                 working copy that were not yet committed to the repository?\nscm>             </expl>\nscm>             <compare>\nscm>                 <s id=\"mercurial\">Yes. Using hg diff.</s>\nscm>                 <s id=\"git\">Yes.\nscm>                     Also, branches are very lightweight in Git, and\nscm>                     could be considered a kind of storage for \"uncommitted\" code\nscm>                     in some workflows.\nscm>                 </s>\n\nA bit rewrapped, and indented.\n\nscm>             </compare>\nscm>         </section>\n\nPerhaps we should add \"Using git diff\" here; the problem is with\n[possible] difference between \"git diff\", \"git diff HEAD\", and\n\"git diff --cached\".\n\nI also think that the comment is not on subject; it is not closely\nrelated to described feature, so it should be IMHO abandoned. The entry\nshould then read:\n\n  Yes. Using git diff. \n\nComments:\n\nI don't think it is worth mentioning the fact that staging area in Git\n(the index) is explicit and visible, and can be directly accessed. In\nusual [newbie] workflows \"git diff\" works just fine...\n\nscm>         <section id=\"per_file_commit_messages\">\nscm>             <title>Per-File Commit Messages</title>\nscm>             <expl>\nscm>                 Does the system have a way to assign a per-file commit message\nscm>                 to the changeset, as well as a per-changeset message?\nscm>             </expl>\nscm>             <compare>\nscm>                 <s id=\"bitkeeper\">Yes. It is possible to have a per-file\nscm>                     commit message</s>\nscm>                 <s id=\"mercurial\">\nscm>                     No.\nscm>                 </s>\nscm>                 <s id=\"git\">\nscm>                     No. Commit messages are per changeset.\nscm>                 </s>\n\nRe-wrapped.\n\nscm>            </compare>\nscm>         </section>\nscm>     </section>\n\nPerhaps simple \"No.\" as in case of Mercurial entry would be enough here?\n\nComments:\n\nWhat is the reason somebody would want per-file commit message?  They\ncannot be terribly useful, as BitKeeper which taught Linus about\ndistributed version control has it, but Git doesn't.\n\nscm>     <section id=\"technical_status\">\nscm>         <title>Technical Status</title>\nscm>         <section id=\"documentation\">\nscm>             <title>Documentation</title>\nscm>             <expl>\nscm>                 How well is the system documented? How easy is it to\nscm>                 get started using it?\nscm>             </expl>\nscm>             <compare>\nscm>                 <s id=\"darcs\">\nscm>                     Good. The manual contains a brief tutorial and a solid\nscm>                     reference.  Every sub-command can print its usage.\nscm>                     Because the command-set is small and the model is\nscm>                     simple, many users find it easy to get started.\nscm>                 </s>\nscm>                 <s id=\"git\">\nscm>                     Medium. The short help is too terse and obscure.\nscm>                     The man pages are extensive, but tend to be confusing.\nscm>                     The are many tutorials.\nscm>                 </s>\n\nRe-wrapped and re-indented for better readibilit.\n\nscm>             </compare>\nscm>         </section>\n\nThat of course depends on ones opinion.  I would say \"Good\", now that\nthere is \"Git User's Manual\" distributed with Git, and now that there\nstarted semi-official \"Git Community Book\" (http://book.git-scm.com).\n\nSo I would say:\n\n  Good. There is extensive <a href=\"\">\"Git User's Manual\"<a/> distributed\n  with Git. There started semi-official <a href=\"http://book.git-scm.com\">\"Git\n  Community Book\". There is manpage for each sub-command, and most commands\n  can print short usage.\n\nComments:\n\nBackward compatibility^W^W Old impressions die hard,... And the meme\nthat git documentation is not user friendly is difficult to kill.\n\nscm>         <section id=\"ease_of_deployment\">\nscm>             <title>Ease of Deployment</title>\nscm>             <expl>\nscm>                 How easy is it to deploy the software? What are\nscm>                 the dependencies and how can they be satisfied?\nscm>             </expl>\nscm>             <compare>\nscm>                 <s id=\"mercurial\">\nscm>                     Excellent.  Binary packages are available for all\nscm>                     popular platforms.  Building from source requires\nscm>                     only Python 2.3 (or later) and a C compiler.\nscm>                 </s>\nscm>                <s id=\"git\">\nscm>                    Good.  Binary packages are available\nscm>                    for modern platforms.  C compiler and Perl are\nscm>                    required. Requires cygwin on Windows, and has some\nscm>                    UNIXisms.\nscm>                </s>\nscm>            </compare>\nscm>         </section>\n\nThanks to msysGit project it is not required to install Cygwin to have\nGit on Windows. Also some commands are still written as shell scripts.\nSo I would say:\n\n  Good. Binary packages are available for modern platforms. On Windows\n  one can use either Cygwin, or native msysGit version. Requires Perl\n  and POSIX shell (and assorted shell tools) for some commands.\n\nComments:\n\nI don't know what to do with \"has some UNIXisms\"; I think it is not\nvery relevant for this entry, and it shouldn't be here.\n\nAs I use Git only on Linux (and at one time used msysGit on MS Windows XP\nand FAT filesystem on USB drive to fetch git.git only), I cannot say much\non ease of deployment on other operating systems, like Free/Open/NetBSD,\nMacOS X, different Unices, and MS Windows.  Perhaps it should be even\n\"Very good\" here?\n\nscm>         <section id=\"command_set\">\nscm>             <title>Command Set</title>\nscm>             <expl>\nscm>                 What is the command set? How compatible is it with\nscm>                 the commands of CVS (the current open-source defacto\nscm>                 standard)?\nscm>             </expl>\nscm>             <compare>\nscm>                 <s id=\"bitkeeper\">\nscm>                     A CVS-like command set with some easy-to-get-used-to\nscm>                     complications due to its different way of work and \nscm>                     philosophy.\nscm>                 </s>\nscm>                 <s id=\"bazaar\">\nscm>                     Tries to follow CVS conventions, but deviates\nscm>                     where there is a different design.\nscm>                 </s>\n\nThe same for Mercurial.\n\nscm>                 <s id=\"git\">\nscm>                     Command set is very feature-rich, and not compatible\nscm>                     with CVS.\nscm>                 </s>\nscm>            </compare>\nscm>         </section>\n\nI don't think the situation is that different than with Mercurial, so\nperhaps it should simply read:\n\n  Tries to follow CVS conventions, but deviates where there is\n  a different design.\n\nAlthough Git doesn't \"try to follow CVS conventions\", it does follow\nBitKeeper convention, then transitively also CVS conventions.  I would\nagree with \"feature-rich\" comment, though ;-)\n\nSo perhaps something like\n\n  Command set is very feature-rich; compatibility with CVS conventions\n  are limited by differences in design.\n\nscm>         <section id=\"networking\">\nscm>             <title>Networking Support</title>\nscm>             <expl>\nscm>                 How good is the networking integration of the system?\nscm>                 How compliant is it with existing protocols and infra-structure?\nscm>             </expl>\nscm>             <compare>\nscm>                 <s id=\"bazaar\">\nscm>                     Excellent. Works natively over HTTP (read-only),\nscm>                     FTP and SFTP without having Bazaar installed at\nscm>                     the remote end.  Works over HTTP, SSH and a custom\nscm>                     protocol when talking to a remote Bazaar\nscm>                     server. Supports RSYNC and WebDAV (experimental)\nscm>                     through plugins.\nscm>                 </s>\nscm>                 <s id=\"mercurial\">\nscm>                     Excellent.  Uses HTTP or ssh.  Remote access also\nscm>                     works safely without locks over read-only network\nscm>                     filesystems.\nscm>                 </s>\nscm>                 <s id=\"git\">\nscm>                     Excellent.  Can use native Git protocol, but works\nscm>                     over rsync, ssh, HTTP and HTTPS also.\nscm>                 </s>\n\nLine-wrapped for better readibility.\n\nscm>             </compare>\nscm>         </section>\n\nIt could be written differently, but basically is O.K. Perhaps we\nshould state explicitely which protocols are read-only, and which allow\nto push (publish) changes to server; which protocols require Git\ninstalled on server and which can do without; perhaps also git-bundle\nfor off-line transport could be mentioned here.\n\nscm>         <section id=\"portability\">\nscm>             <title>Portability</title>\nscm>             <expl>\nscm>                 How portable is the version-control system to various \nscm>                 operating systems, computer architectures, and other\nscm>                 types of systems?\nscm>             </expl>\nscm>             <compare>\nscm>                 <s id=\"mercurial\">\nscm>                     Excellent. Runs on all platforms supported by\nscm>                     Python.  Repositories are portable across CPU\nscm>                     architectures and endian conventions.\nscm>                 </s>\nscm>                 <s id=\"perforce\">\nscm>                     Excellent. Runs on UNIX, Mac OS, BeOS and Windows.\nscm>                 </s>\nscm>                 <s id=\"git\">\nscm>                     The client works on most UNIXes, but not on native\nscm>                     MS-Windows. The Cygwin build seems to be workable, though.\nscm>                 </s>\n\nRe-wrapped for better readibility.\n\nscm>             </compare>\nscm>         </section>\nscm>     </section>\n\nThere is native MS Windows implementation named msysGit. We can also\nmention that Git runs on Linux, Free/Open/NetBSD, various Unices, \nMacOX X.\n\nThe entry for Git lacks also single word descriptions, like \"Excellent\",\n\"Very good\", \"Good\", \"Medium\", that most other SCM have in this part\n(and \"Windows only\" for some).\n\nSo I would say something like the following:\n\n  Very good. Works on Linux, FreeBSD, MacOS X and various Unices. Works\n  on MS Windows either via Cygwin, or natively via msysGit.\n\nPerhaps I would also add the following cautionary note:\n\n  There are some issues with case-insensitive (e.g. FAT) or filename-mangling\n  (MacOS HFS+) filesystems, but they can be worked around.\n\nComments:\n\nI'm not sure if it should be \"Very good\" or \"Excellent\" here. I think\nthat this section is about number of systems SCM was ported to, not\nhow hard is to make it work (port Git) on some additional OS. I'm not\nsure how complete msysGit is (git-svn and other Perl scripts), so I put\n\"Very good\"; but it is improving, buth thanks to builtinification and\nto efforts of msysGit maintainers and developers.\n\nscm>     <section id=\"user_interaces\">\nscm>         <title>User Interfaces</title>\nscm>         <section id=\"web_interface\">\nscm>             <title>Web Interface</title>\nscm>             <expl>\nscm>                 Does the system have a WWW-based interface that can be\nscm>                 used to browse the tree and the various revisions of the\nscm>                 files, perform arbitrary diffs, etc?\nscm>             </expl>\nscm>             <compare>\nscm>                 <s id=\"cvs\">Yes. \nscm>                     <a href=\"http://www.freebsd.org/projects/cvsweb.html\">CVSweb</a>,\nscm>                     <a href=\"http://www.viewvc.org/\">ViewVC</a>,\nscm>                     <a href=\"http://www.horde.org/chora/\">Chora</a>,\nscm>                     and <a href=\"http://wwcvs.republika.pl/\">wwCVS</a>.\nscm>                 </s>\nscm>                 <s id=\"bazaar\">\nscm>                     Yes, several:\nscm>                     <a href=\"http://www.lag.net/loggerhead/\">Loggerhead</a>,\nscm>                     <a href=\"http://goffredo-baroncelli.homelinux.net/bazaar/\">Webserve</a>,\nscm>                     <a href=\"http://mccormick.cx/dev/bzrweb/index.py/log/bzrweb/head\">Bzrweb</a>,\nscm>                     and\nscm>                     <a href=\"http://bazaar-vcs.org/TracBzr\">Trac</a>.\nscm>                 </s>\nscm>                 <s id=\"mercurial\">Yes.  The web interface is a bundled component.</s>\nscm>                 <s id=\"git\">\nscm>                     Yes.  Gitweb is included in distribution.\nscm>                 </s>\nscm>             </compare>\nscm>         </section>\n\nFor other SCMs there are listed many different web interfaces.\nSo I would perhaps put here a list:\n\n  Yes.  Gitweb (in Perl) is included in distribution, but there are\n  many other web interfaces:\n  <a href=\"http://hjemli.net/git/cgit/\">cgit</a> (in C),\n  <a href=\"http://code.google.com/p/git-php/\">git-php</a> and\n  <a href=\"http://people.proekspert.ee/peeter/blog/index.php?category=5\">its fork<a> (in PHP),\n  <a href=\"http://viewgit.sourceforge.net/\">ViewGit</a> (in PHP),\n  <a href=\"http://www.flameeyes.eu/projects#gitarella\">Gitarella</a> (in Ruby)\n\nPerhaps we should leave programming language used, as there is no such\ninformation provided for other SCM listed in comparison.\n\nComments:\n\nI have not put Wit by Daniel Chokola in Ruby/eRuby, as the site seems\nto be down. I also didn't add GitStat which is not web interface but\noffers instead web-based statistics about repository, and hosting\nsolutions such as Gitorious (in Ruby), InDefero (in PHP) and GitHub\n(not open, in Ruby).\n\nI'm also not sure which one of git-php implementations to list; perhaps\nsimply the first one, the one that has kind of homepage on Google Code.\n\nscm>         <section id=\"availability_of_guis\">\nscm>             <title>Availability of Graphical User-Interfaces.</title>\nscm>             <expl>\nscm>                 What is the availability of graphical user-interfaces for\nscm>                 the system? How many GUI clients are present for it?\nscm>             </expl>\nscm>             <compare>\nscm>                 <s id=\"bazaar\">\nscm>                     There are several graphical frontends in\nscm>                     development,\nscm>                     see <a href=\"http://bazaar-vcs.org/BzrPlugins\">the Bazaar Plugins page</a>\nscm>                     and <a href=\"http://bazaar-vcs.org/3rdPartyTools\">the Third-party Tools page</a>.\nscm>                     Notable\nscm>                     are <a href=\"http://bazaar-vcs.org/QBzr\">QBzr\nscm>                     (Qt)</a> and \nscm>                     <a href=\"http://bazaar-vcs.org/bzr-gtk\">bzr-gtk (GTK+)</a>, which\nscm>                     can be considered beta quality.  Work is also\nscm>                     being done on integrating Bazaar with Windows\nscm>                     Explorer, Eclipse, Nautilus, and Meld.\nscm>                 </s>\nscm>                 <s id=\"mercurial\">\nscm>                     History viewing available with hgit extension;\nscm>                     check-in extension (hgct) makes committing easier.\nscm>                     Some third-party IDEs and GUI tools (e.g. eric3,\nscm>                     meld) have integrated Mercurial support.\nscm>                 </s>\nscm>                 <s id=\"git\">\nscm>                     Gitk is included in distribution.  \nscm>                     Qgit and Git-gui tools are also available.\nscm>                 </s>\n\nRe-wrapped.\n\nscm>            </compare>\nscm>         </section>\nscm>     </section>\n\nThere is a question whether to list all (or at least more popular) GUI\ntools, or list only built-in and perhaps one or two more, and direct\nto Git Wiki for details, like below:\n\n  Gitk history viewer and Git-gui commit tool are included in distribution.\n  There are also other tools available, like\n  <a href=\"http://digilander.libero.it/mcostalba/\">QGit</a> (Qt) nad\n  <a href=\"http://github.com/Caged/gitnub/wikis\">GitNub</a> (MacOS);\n  see <a href=\"http://git.or.cz/gitwiki/InterfacesFrontendsAndTools#gui\">Interfaces,\n  Frontends And Tools</a> page on Git Wiki for a list.\n\nI have listed two most popular GUI according to currently open survey\n  http://www.survs.com/shareResults?survey=M3PIVU72&rndm=OKJQ45LAG8\n\nComments:\n\nShould there be mentioned integration and beginning of integration with\nIDE, editors and other tools in the form of EGit (Eclipse Git plugin),\nsimilar work for NetBeans and IntelliJ/JetBeans, Git TextMate bundle,\nEmacs modes (git.el, vc-git.el, DVC, magit), and support from other\ntools like PIDA and Meld?  It is mentioned for other SCM, but it is\nnot GUI in exact meaning of this word.\n\nscm>     <section id=\"license\">\nscm>         <title>License</title>\nscm>         <expl>\nscm>             What are the licensing terms for the software? \nscm>         </expl>\nscm>         <compare>\nscm>             <s id=\"mercurial\">GNU GPL (open source)</s>\nscm>             <s id=\"git\">GNU GPL v2 (open source).</s>\nscm>         </compare>\nscm>     </section>\nscm> </section>\n\nNo comments here.\n\n-- \nJakub Narebski\nPoland\n"}]}