{"thread":{"id":"11226","subject":"Adding Git to Better SCM Initiative : Comparison","startedAt":"2007-12-10T12:57:48Z","lastAt":"2008-01-14T12:14:20Z","messageCount":17,"participants":["Jakub Narebski","Eyvind Bernhardsen","David Kastrup","Florian Weimer","Johannes Schindelin","Linus Torvalds","Chris Shoemaker","Dmitry Potapov"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"62569","messageId":"200712101357.49325.jnareb@gmail.com","threadId":"11226","inReplyTo":null,"subject":"Adding Git to Better SCM Initiative : Comparison","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-12-10T12:57:48Z","receivedAt":"2007-12-10T12:57:48Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"I have noticed that your SCM comparison at \"Better SCM Initiative\"\nwebsite\n http://better-scm.berlios.de/comparison/comparison.html\nmisses one of the Git, version control system which is used to manage\nLinux kernel, and one of the main open source (distributed) version\ncontrol systems (among Mercurial, Bazaar-NG, Monotone and Darcs).\n\nGit used to be \"stupid content tracker\", something to build\nuser-friendly SCM interface on (e.g. Cogito) but it evolved into fully\nfledged SCM since.\n\nGit was created by Linus Torvalds in response to the change of BitKeeper \nlicensing, as a tool to manage Linux kernel sources. It is based on \nthree years of Linus experience with BitKeeper, and inspired by \nMonotone architecture. It was designed for Linux kernel, and is used\nby various projects, including X.Org, various Freedesktop projects,\nWINE, OLPC (One Laptop Per Child), Samba.\n\n\nGit is a popular version control system designed to handle very large\nprojects with speed and efficiency; it is used mainly for various open\nsource projects, most notably the Linux kernel.\n\nGit falls in the category of distributed source code management tools,\nsimilar to e.g. GNU Arch or Monotone (or BitKeeper in the proprietary\nworld). Every Git working directory is a full-fledged repository with\nfull revision tracking capabilities, not dependent on network access or\na central server.\n\nGit is an Open Source project covered by the GNU General Public License v2.\nIt was originally written by Linus Torvalds and is currently maintained\nby Junio C Hamano.\n\n\nBelow there is (slightly doctored) patch to the sources for the site.\n\n\nBTW. when asking about updating GIT info for comparison, please CC\ngit mailing list, git@vger.kernel.org\n\n\nIndex: src/comparison/scm-comparison.xml\n===================================================================\n--- src/comparison/scm-comparison.xml (revision 290)\n+++ src/comparison/scm-comparison.xml (working copy)\n@@ -38,6 +38,9 @@ \n \n Darcs\n \n+ \n+ Git\n+ \n \n Mercurial\n \n@@ -106,6 +109,7 @@ Atomic Commits\n Commits are atomic.\n Commits are atomic.\n Yes (but need to verify)\n+ Yes.\n Yes.\n Yes.\n Yes. Commits are atomic.\n@@ -142,6 +146,13 @@ Files and Directories Moves or Renames\n Yes. Renames are supported.\n Yes. Renames are supported.\n Yes. Renames are supported.\n+ \n+ Yes (or no depending on interpretation). Git detects\n+ renames based on content regardless of whether the\n+ committer indicated the fact.\n+ You can follow history of file across renames using\n+ 'git log -M --follow'.\n+ \n Yes. Renames are supported.\n Yes. Renames are supported.\n Yes. Renames are supported\n@@ -214,6 +225,13 @@ File and Directories Copies\n Yes. Copies are supported.\n \n No. Copies are not supported.\n+ \n+ Yes (or no depending on interpretation). Git detects\n+ copies (when requested) based on content regardless\n+ of whether the committer indicated the fact.\n+ You can follow history of file across copies using\n+ 'git log -C -C --follow'.\n+ \n Yes. Copies are supported\n Yes. Copies are supported\n No. Copies are not supported.\n@@ -267,6 +285,7 @@ Remote Repository Replication\n Yes.\n Yes.\n Yes.\n+ Yes.\n Yes.\n Yes.\n No.\n@@ -313,6 +332,7 @@ Propagating Changes to Parent Repositories\n Yes.\n Yes.\n Yes.\n+ Yes.\n Yes.\n Yes.\n No.\n@@ -373,6 +393,10 @@ Repository Permissions\n \n Same as subversion.\n \n+ \n+ Partial (?). It is possible to lock down repository\n+ (access to branches and tags) using hooks.\n+ \n \n Yes. It is possible to lock down repositories,\n subdirectories, or files using hooks.\n@@ -455,6 +479,13 @@ Changesets' Support\n \n Yes. Changesets are supported.\n \n+ \n+ Yes. Changesets are supported.
\n+ Actually Git is snapshot based which means Git records\n+ the full state in every commit. This means that any two\n+ commits can be compared directly very quickly, although the\n+ repository is typically browsed as a series of changesets.\n+ \n \n Yes. Changesets are supported.\n \n@@ -509,6 +540,11 @@ Tracking Line-wise File History\n Not in the command line client, but ViewARCH,\n a web-interface for Arch, has it.\n Yes. (darcs annotate)\n+ \n+ Yes. (git blame, git gui blame).\n+ It can also detect the origin of copied and moved source\n+ lines, and can ignore whitespace changes.\n+ \n Yes. (hg annotate)\n Yes, as of version 0.19.\n Yes. aeannotate\n@@ -570,6 +606,11 @@ Ability to Work only on One Directory...\n whole.\n \n No. All changes are made repository-wide.\n+ \n+ No. All changes are made repository-wide. However\n+ it is possible to commit only selected changes in the\n+ working tree rather than everything. You can also\n+ use submodules (subproject) support.\n \n It is possible to commit changes only in a subset of the\n tree. There are plans for partial checkouts.\n@@ -636,6 +677,10 @@ Tracking Uncommited Changes\n Yes, using \"darcs whatsnew\".\n \n Yes. Using aediff\n+ \n+ Yes, of course. Using git diff.\n+ Note that git uses staging area for commits (index).\n+ \n Yes. Using hg diff.\n Yes. In a similar fashion to CVS.\n Yes. Using cm diff\n@@ -681,6 +726,11 @@ Per-File Commit Messages\n \n No.\n \n+ \n+ No. The message applies to the commit as a whole.\n+ But you can tag (with description) given contents\n+ of a file (blob).\n+ \n \n No.\n \n@@ -782,6 +832,15 @@ Documentation\n and the client contains a help tool that offers\n an integrated help system.\n \n+ \n+ Good. There's Git User's Manual, manpages, some\n+ technical documentation and some howtos. All\n+ documentation is also available\n+ online\n+ in HTML format; there is additional information (including\n+ beginnings of FAQ) on a\n+ git wiki.\n+ \n \n Very good. There's an overview and tutorial on the\n web site, and integrated help for every command.\n@@ -894,6 +953,16 @@ Ease of Deployment\n to install the subversion perl bindings and a few modules\n from CPAN.\n \n+ \n+ Very good. Install from RPM or deb on Linux; use\n+ msysGit or Cygwin install on Windows. Git requires\n+ zlib; also POSIX shell and utilities and Perl for some\n+ commands.\n+ Installing from sources is easy: Makefile has ready\n+ configuration for many OS, you can also use autoconf\n+ to generate Makefile configuration. Compiling docs\n+ requires asciidoc toolchain, but you can use prebuild.\n+ \n \n Excellent. Binary packages are available for all\n popular platforms. Building from source requires\n@@ -1006,6 +1075,13 @@ Command Set\n but since the model is different most commands are\n unique.\n \n+ \n+ Tries to follow CVS conventions, but deviates where there\n+ is a different design (following BitKeeper for DVCS).\n+ Large command set (~140) is divided into plumbing commands\n+ (low lewel, to be used in scripts) and porcelain (high level).\n+ It is easy to add new commands as scripts, or as git aliases.\n+ \n \n Tries to follow CVS conventions, but deviates where there\n is a different design.\n@@ -1106,6 +1182,13 @@ Networking Support\n There exists some HTTP-functionality, but it is quite\n limited.\n \n+ \n+ Excellent. Uses HTTPS (with WebDAV) or ssh for push\n+ (to publish changes to server) and HTTP, FTP, ssh or custom\n+ \"git\" protocol for fetch (read from server). There is also\n+ git-bundle for offline transport, and tools to exchange\n+ (create and apply) patches via email.\n+ \n \n Excellent. Uses HTTP or ssh. Remote access also\n works safely without locks over read-only network\n@@ -1203,6 +1286,11 @@ Portability\n Very good. Supports many UNIXes, Mac OS X, and Windows,\n and is written in a portable language.\n \n+ \n+ Good to very good. Portable across all POSIX systems.\n+ There exists Win32 binary using MinGW (msysGit),\n+ or you can use binary provided by Cygwin.\n+ \n \n Excellent. Runs on all platforms supported by\n Python. Repositories are portable across CPU\n@@ -1300,6 +1388,10 @@ Web Interface\n is included in the distribution.\n \n Yes.\n+ \n+ Yes, gitweb is included in git since version 1.4.0.\n+ Other web interfaces exists: cgit, wit, git-php\n+ \n Yes. The web interface is a bundled component.\n No.\n No.\n@@ -1373,6 +1464,12 @@ Availability of Graphical User-Interfaces.\n \n There is tkaegis.\n \n+ \n+ There is history viewer 'gitk' and commit tool 'git-gui';\n+ both in Tcl/Tk. There also exists a number of third-party\n+ GUIs, including: qgit (Qt), GitView (GTK+), Giggle (GTK+),\n+ tig (ncurses).\n+ \n \n History viewing available with hgit extension;\n check-in extension (hgct) makes committing easier.\n@@ -1453,6 +1550,7 @@ License\n GNU GPL (open-source)\n \n Perl License. (open source)\n+ GNU GPL v2 (open source)\n GNU GPL (open source)\n GNU GPL (open source)\n \n"},{"id":"62571","messageId":"E876AFC0-498C-48B4-8B83-DB44585F76C5@orakel.ntnu.no","threadId":"11226","inReplyTo":"200712101357.49325.jnareb@gmail.com","subject":"Re: Adding Git to Better SCM Initiative : Comparison","fromName":"Eyvind Bernhardsen","fromEmail":"eyvind-git@orakel.ntnu.no","sentAt":"2007-12-10T13:09:11Z","receivedAt":"2007-12-10T13:09:11Z","isPatch":false,"sender":{"key":"eyvind.bernhardsen@gmail.com","avatar":"https://avatars.githubusercontent.com/u/106762?v=4"},"body":"On 10. des. 2007, at 13.57, Jakub Narebski wrote:\n\n> I have noticed that your SCM comparison at \"Better SCM Initiative\"\n> website\n> http://better-scm.berlios.de/comparison/comparison.html\n> misses one of the Git, version control system which is used to manage\n\n\"misses one of the Git\"?\n-- \nEyvind\n"},{"id":"62573","messageId":"200712101420.03165.jnareb@gmail.com","threadId":"11226","inReplyTo":"E876AFC0-498C-48B4-8B83-DB44585F76C5@orakel.ntnu.no","subject":"Re: Adding Git to Better SCM Initiative : Comparison","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-12-10T13:20:02Z","receivedAt":"2007-12-10T13:20:02Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Eyvind Bernhardsen wrote:\n> On 10. des. 2007, at 13.57, Jakub Narebski wrote:\n> \n>> I have noticed that your SCM comparison at \"Better SCM Initiative\"\n>> website\n>> http://better-scm.berlios.de/comparison/comparison.html\n>> misses one of the Git, version control system which is used to manage\n> \n> \"misses one of the Git\"?\n\nGaaah... I started to write \"misses one of the main OSS DSCM\", but end \nup with \"misses Git [...] one of the main open source (distributed) \nversion control systems\"... and forgot to remove \"one of the\".\n\n-- \nJakub Narebski\nPoland\n"},{"id":"62576","messageId":"85r6hupql3.fsf@lola.goethe.zz","threadId":"11226","inReplyTo":"200712101357.49325.jnareb@gmail.com","subject":"Re: Adding Git to Better SCM Initiative : Comparison","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-12-10T14:33:12Z","receivedAt":"2007-12-10T14:33:12Z","isPatch":false,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Jakub Narebski writes:\n\n> Git was created by Linus Torvalds in response to the change of BitKeeper \n> licensing, as a tool to manage Linux kernel sources. It is based on \n> three years of Linus experience with BitKeeper, and inspired by \n\nof Linus' experience\n\n> Monotone architecture. It was designed for Linux kernel, and is used\n\nMonotone's architecture.\n\n-- \nDavid Kastrup, Kriemhildstr. 15, 44793 Bochum\n"},{"id":"62578","messageId":"87ve76mwos.fsf@mid.deneb.enyo.de","threadId":"11226","inReplyTo":"200712101357.49325.jnareb@gmail.com","subject":"Re: Adding Git to Better SCM Initiative : Comparison","fromName":"Florian Weimer","fromEmail":"fw@deneb.enyo.de","sentAt":"2007-12-10T14:49:39Z","receivedAt":"2007-12-10T14:49:39Z","isPatch":false,"sender":{"key":"fw@deneb.enyo.de","avatar":null},"body":"* Jakub Narebski:\n\n> + \n> + Yes (or no depending on interpretation). Git\n\nThis should be \"No.\" (same for copies below).\n\n> + \n> + Partial (?). It is possible to lock down repository\n> + (access to branches and tags) using hooks.\n> + \n\nI doubt this works reliably. You still can access data once you've got\nits SHA1 hash, for instance.\n\n> + \n> + Yes. Changesets are supported.
\n> + Actually Git is snapshot based which means Git records\n> + the full state in every commit. This means that any two\n> + commits can be compared directly very quickly, although the\n> + repository is typically browsed as a series of changesets.\n> + \n\nI don't think this explanation is necessary. What does Subversion say?\n\n> + \n> + Yes. (git blame, git gui blame).\n> + It can also detect the origin of copied and moved source\n> + lines, and can ignore whitespace changes.\n> + \n\nA simple \"Yes.\" should suffice.\n\n> @@ -636,6 +677,10 @@ Tracking Uncommited Changes\n> Yes, using \"darcs whatsnew\".\n> \n> Yes. Using aediff\n> + \n> + Yes, of course. Using git diff.\n> + Note that git uses staging area for commits (index).\n> + \n\nSimply \"Yes.\". \"git diff\" is wrong, it's actually \"git diff HEAD\".\n\n> @@ -681,6 +726,11 @@ Per-File Commit Messages\n> \n> No.\n> \n> + \n> + No. The message applies to the commit as a whole.\n> + But you can tag (with description) given contents\n> + of a file (blob).\n> + \n\nHave we got any real tool support for this? This should be \"No.\".\n\n> @@ -1006,6 +1075,13 @@ Command Set\n> but since the model is different most commands are\n> unique.\n> \n> + \n> + Tries to follow CVS conventions, but deviates where there\n> + is a different design (following BitKeeper for DVCS).\n\nI don't think this is true. Is there any command that closely matches\nwhat CVS does?\n\n> @@ -1203,6 +1286,11 @@ Portability\n> Very good. Supports many UNIXes, Mac OS X, and Windows,\n> and is written in a portable language.\n> \n> + \n> + Good to very good. Portable across all POSIX systems.\n> + There exists Win32 binary using MinGW (msysGit),\n> + or you can use binary provided by Cygwin.\n> + \n\nIsn't Windows support still a bit lacking in terms of performance?\n"},{"id":"62582","messageId":"Pine.LNX.4.64.0712101522290.27959@racer.site","threadId":"11226","inReplyTo":"87ve76mwos.fsf@mid.deneb.enyo.de","subject":"Re: Adding Git to Better SCM Initiative : Comparison","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-12-10T15:23:23Z","receivedAt":"2007-12-10T15:23:23Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Mon, 10 Dec 2007, Florian Weimer wrote:\n\n> * Jakub Narebski:\n> \n> > + \n> > + Yes (or no depending on interpretation). Git\n> \n> This should be \"No.\" (same for copies below).\n\nNice. I have no idea what you are talking about, as you only quoted the \nanswer, but not the question. (Same for the other quoted text.)\n\nThanks,\nDscho\n"},{"id":"62584","messageId":"8763z6mujd.fsf@mid.deneb.enyo.de","threadId":"11226","inReplyTo":"Pine.LNX.4.64.0712101522290.27959@racer.site","subject":"Re: Adding Git to Better SCM Initiative : Comparison","fromName":"Florian Weimer","fromEmail":"fw@deneb.enyo.de","sentAt":"2007-12-10T15:36:06Z","receivedAt":"2007-12-10T15:36:06Z","isPatch":false,"sender":{"key":"fw@deneb.enyo.de","avatar":null},"body":"* Johannes Schindelin:\n\n>> > + \n>> > + Yes (or no depending on interpretation). Git\n>> \n>> This should be \"No.\" (same for copies below).\n>\n> Nice. I have no idea what you are talking about, as you only quoted the \n> answer, but not the question. \n\nOops. It's about the rename/copy detection stuff.\n\n> (Same for the other quoted text.)\n\nI tried to provide more context in those cases; the @@ lines should be\nsufficient, I guess.\n"},{"id":"62586","messageId":"m34peqtuuj.fsf@roke.D-201","threadId":"11226","inReplyTo":"87ve76mwos.fsf@mid.deneb.enyo.de","subject":"Re: Adding Git to Better SCM Initiative : Comparison","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-12-10T15:47:49Z","receivedAt":"2007-12-10T15:47:49Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Florian Weimer writes:\n\n> * Jakub Narebski:\n> > @@ -214,6 +225,13 @@ File and Directories Copies\n[...]\n> > + \n> > + Yes (or no depending on interpretation). Git\n> \n> This should be \"No.\" (same for copies below).\n\nI would agree to \"N/A\" or \"Partial\", but with 'git log --follow'\nimplemented at least for single file I wouldn't say that that git\ndoesn't support file and directories renames (copies). It does, in\nit's own fashion, using rename (copy) detection instead of rename\n(copy) tracking.\n\nBy the way, the explanation for \"File and Directories Copies\" section\nitself is a bit imprecise; well at least it doesn't lead to easy\nanswer for git. I took it as question if we can examine _history_\nof a file (or directory) across renames (copies). Other\ninterpretation would be if version control system in question\ncorrectly handles renames and copies during merges... but it is in\nTODO (Add intelligent merging of renamed paths.)\n \n> > + \n> > + Partial (?). It is possible to lock down repository\n> > + (access to branches and tags) using hooks.\n> > + \n> \n> I doubt this works reliably. You still can access data once you've got\n> its SHA1 hash, for instance.\n\nSo what? The data is not visible, so it is as if it didn't\nexist. Besides if you are truly paranoid you can I think remove\ndownloaded pack.\n\nBy the way the default 'contrib/hooks/update-paranoid' implements ACL\nrestricting access to branches and tags, but I think that you can\nwrite a hook which would refuse update if there are changes outside\nspecified subdirectory for example.\n\nNote however that \"repository permissions\" are much more important for\ncentralized SCMs than for distributed SCMs, where you can form\n\"network of trust\" (like Linus with his kernel's lieutenants and\nsubsystem maintainers).\n\n> > + \n> > + Yes. Changesets are supported.
\n> > + Actually Git is snapshot based which means Git records\n> > + the full state in every commit. This means that any two\n> > + commits can be compared directly very quickly, although the\n> > + repository is typically browsed as a series of changesets.\n> > + \n> \n> I don't think this explanation is necessary. What does Subversion say?\n\nSubversion has the following currently:\n\n Partial support. There are implicit changeset that are generated on\n each commit.\n\n\nWell, we could follow Mercurial, Monotone and Darcs and simply write\n\n+ \n+ Yes. Changesets are supported.\n+ \n\n> > + \n> > + Yes. (git blame, git gui blame).\n> > + It can also detect the origin of copied and moved source\n> > + lines, and can ignore whitespace changes.\n> > + \n> \n> A simple \"Yes.\" should suffice.\n\nEach SCM names the command for displaying line-wise file history,\nif it of course exists.\n\nWhile \"can ignore whitespace changes\" is not that important, detection\nof contents movement and copying is important differentiation,\npossible (or at least implemented) because Git uses rename detection\nrather than rename tracking.\n \n> > @@ -636,6 +677,10 @@ Tracking Uncommited Changes\n> > Yes, using \"darcs whatsnew\".\n> > \n> > Yes. Using aediff\n> > + \n> > + Yes, of course. Using git diff.\n> > + Note that git uses staging area for commits (index).\n> > + \n> \n> Simply \"Yes.\". \"git diff\" is wrong, it's actually \"git diff HEAD\".\n\nActually it depends on the definition of \"uncommitted changes\".\nBesides \"git diff HEAD\" _is_ \"using git diff\".\n\nBut it's true that 'of course' there is not needed.\n\n> > @@ -681,6 +726,11 @@ Per-File Commit Messages\n> > \n> > No.\n> > \n> > + \n> > + No. The message applies to the commit as a whole.\n> > + But you can tag (with description) given contents\n> > + of a file (blob).\n> > + \n> \n> Have we got any real tool support for this? This should be \"No.\".\n\nTrue. But I'd rather leave it as \"No. The message applies to the\ncommit as a whole.\" because that is important property.\n\n> > @@ -1006,6 +1075,13 @@ Command Set\n> > but since the model is different most commands are\n> > unique.\n> > \n> > + \n> > + Tries to follow CVS conventions, but deviates where there\n> > + is a different design (following BitKeeper for DVCS).\n> \n> I don't think this is true. Is there any command that closely matches\n> what CVS does?\n\nYes: init, add, annotate (alias to blame), checkout, commit, diff,\nstatus, log, version. At least in principle, if not in output format.\n\nI don't think that Mercurial and Monotone follow CVS much better than\nGit. (But that was one of answers I was having problems with.)\n\n> > @@ -1203,6 +1286,11 @@ Portability\n> > Very good. Supports many UNIXes, Mac OS X, and Windows,\n> > and is written in a portable language.\n> > \n> > + \n> > + Good to very good. Portable across all POSIX systems.\n> > + There exists Win32 binary using MinGW (msysGit),\n> > + or you can use binary provided by Cygwin.\n> > + \n> \n> Isn't Windows support still a bit lacking in terms of performance?\n\nThat is more a problem with Windows, than Git ;-)\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"62591","messageId":"87r6huldjw.fsf@mid.deneb.enyo.de","threadId":"11226","inReplyTo":"m34peqtuuj.fsf@roke.D-201","subject":"Re: Adding Git to Better SCM Initiative : Comparison","fromName":"Florian Weimer","fromEmail":"fw@deneb.enyo.de","sentAt":"2007-12-10T16:28:19Z","receivedAt":"2007-12-10T16:28:19Z","isPatch":false,"sender":{"key":"fw@deneb.enyo.de","avatar":null},"body":"* Jakub Narebski:\n\n> Florian Weimer writes:\n>\n>> * Jakub Narebski:\n>> > @@ -214,6 +225,13 @@ File and Directories Copies\n> [...]\n>> > + \n>> > + Yes (or no depending on interpretation). Git\n>> \n>> This should be \"No.\" (same for copies below).\n>\n> I would agree to \"N/A\" or \"Partial\", but with 'git log --follow'\n> implemented at least for single file I wouldn't say that that git\n> doesn't support file and directories renames (copies). It does, in\n> it's own fashion, using rename (copy) detection instead of rename\n> (copy) tracking.\n\nIt's undoubtly a difficult question. In my experience, developers tend\nto not mark renames properly, so rename detection in log/diff/annotate\nis still helpful even if renames are encoded explicitly. But this was a\nlearning process; I used to think that explicit rename support was\nessential.\n\n>> > + \n>> > + Partial (?). It is possible to lock down repository\n>> > + (access to branches and tags) using hooks.\n>> > + \n>> \n>> I doubt this works reliably. You still can access data once you've got\n>> its SHA1 hash, for instance.\n>\n> So what? The data is not visible, so it is as if it didn't\n> exist.\n\nUhm, I'd commit something that references some SHA-1, and voilà, I can\nread the object with that SHA-1.\n\n>> > + \n>> > + Yes. Changesets are supported.
\n>> > + Actually Git is snapshot based which means Git records\n>> > + the full state in every commit. This means that any two\n>> > + commits can be compared directly very quickly, although the\n>> > + repository is typically browsed as a series of changesets.\n>> > + \n>> \n>> I don't think this explanation is necessary. What does Subversion say?\n>\n> Subversion has the following currently:\n>\n> Partial support. There are implicit changeset that are generated on\n> each commit.\n\nHmm.\n\n> Well, we could follow Mercurial, Monotone and Darcs and simply write\n>\n> + \n> + Yes. Changesets are supported.\n> + \n\nMakes sense, especially since there's \"git bundle\" nowadays.\n\n>> I don't think this is true. Is there any command that closely matches\n>> what CVS does?\n>\n> Yes: init, add, annotate (alias to blame), checkout, commit, diff,\n> status, log, version. At least in principle, if not in output format.\n\nI think we disagree on the meaning of \"close\" here. 8-/\n\nIn my experience, it's hard to see the parallels between GIT and CVS\nbecause the semantics are so different. This is, to some extent,\nunavoidable. But I'm not sure if knowing your way around CVS actually\nhelps learning GIT (the old sayings about BASIC come to my mind).\n"},{"id":"62594","messageId":"alpine.LFD.0.9999.0712100837300.12046@woody.linux-foundation.org","threadId":"11226","inReplyTo":"87ve76mwos.fsf@mid.deneb.enyo.de","subject":"Re: Adding Git to Better SCM Initiative : Comparison","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-12-10T16:38:33Z","receivedAt":"2007-12-10T16:38:33Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Mon, 10 Dec 2007, Florian Weimer wrote:\n\n> * Jakub Narebski:\n> \n> > + \n> > + Yes (or no depending on interpretation). Git\n> \n> This should be \"No.\" (same for copies below).\n\nNo.\n\nGit handles renames and copies better than most SCM's that _claim_ to \nhandle them. Saying we don't do them is just stupid. We do them *right*. \nThe fact that inferior systems do it differently is _their_ problem, and \nnot a cause for saying that git wouldn't do them.\n\n\t\tLinus\n"},{"id":"62598","messageId":"20071210165052.GA22327@pe.Belkin","threadId":"11226","inReplyTo":"87ve76mwos.fsf@mid.deneb.enyo.de","subject":"Re: Adding Git to Better SCM Initiative : Comparison","fromName":"Chris Shoemaker","fromEmail":"c.shoemaker@cox.net","sentAt":"2007-12-10T16:50:52Z","receivedAt":"2007-12-10T16:50:52Z","isPatch":false,"sender":{"key":"c.shoemaker@cox.net","avatar":null},"body":"On Mon, Dec 10, 2007 at 03:49:39PM +0100, Florian Weimer wrote:\n> * Jakub Narebski:\n> \n> > + \n> > + Yes (or no depending on interpretation). Git\n> \n> This should be \"No.\" (same for copies below).\n\nISTM that people are stuck using less than helpful criteria for\njudging whether renames are supported. Namely, in effect, they ask:\n\"Does the user get to do extra work in order to get rename-detection?\"\n\nLet me humbly suggest an alternate, two-fold, very practical criteria\nthat I actually care about as a user:\n\n1) If I edit file A, while another developer renames file A to B, and\nI merge my work with his, do I have to clean things up myself, or does\neverything Just Work?\n\n2) If I'm browsing the history of some code in a renamed file, does\nthe history continue through the rename?\n\nBy these criteria, git certainly does support renames.\n\n-chris\n"},{"id":"62600","messageId":"m3zlwisbxx.fsf@roke.D-201","threadId":"11226","inReplyTo":"20071210165052.GA22327@pe.Belkin","subject":"Re: Adding Git to Better SCM Initiative : Comparison","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-12-10T17:21:26Z","receivedAt":"2007-12-10T17:21:26Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Chris Shoemaker writes:\n\n> On Mon, Dec 10, 2007 at 03:49:39PM +0100, Florian Weimer wrote:\n> > * Jakub Narebski:\n> > \n> > > + \n> > > + Yes (or no depending on interpretation). Git\n> > \n> > This should be \"No.\" (same for copies below).\n> \n> ISTM that people are stuck using less than helpful criteria for\n> judging whether renames are supported. Namely, in effect, they ask:\n> \"Does the user get to do extra work in order to get rename-detection?\"\n> \n> Let me humbly suggest an alternate, two-fold, very practical criteria\n> that I actually care about as a user:\n> \n> 1) If I edit file A, while another developer renames file A to B, and\n> I merge my work with his, do I have to clean things up myself, or does\n> everything Just Work?\n\nThe only thing Git doesn't implement _yet_ is when you have renamed\na directory, and another developer created a new file in the old\ndirectory name. Currently Git creates new files in old directory.\nNote however that moving files to other directory might need changes\nin files: for example Java, or header files includes in C/C++. This\nis not very common, though.\n\nBTW. this issue is in TODO for \"Better SCM : Comparison\"\n * Add intelligent merging of renamed paths.\n\n> 2) If I'm browsing the history of some code in a renamed file, does\n> the history continue through the rename?\n\nAnd Git does support it in both \"git blame\" (or \"git gui blame\"),\nand in \"git log\" thanks to --follow option.\n\nNote however that --follow cannot be used (yet?) with directories or\npathspecs. Not that other SCMs support wildcard pathspec limiting...\n\n> By these criteria, git certainly does support renames.\n\nThat's why I wrote \"Yes\", adding \"or no\" (as suggested by Robin\nRosenberg) because it does it dofferently than other SCMs.\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"65223","messageId":"200801130144.14574.jnareb@gmail.com","threadId":"11226","inReplyTo":"200801071057.27710.shlomif@iglu.org.il","subject":"Re: Adding Git to Better SCM Initiative : Comparison","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-01-13T00:44:10Z","receivedAt":"2008-01-13T00:44:10Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Mon, 7 Jan 2008, Shlomi Fish wrote:\n> \n> I'm CCing all the correspondents, because I'm banned from the vger.kernel.org \n> mail. This has been an obstacle for me in several legitimate occassions and \n> this one is the latest. I'm still CCing it, so the people in the mailing list \n> will receive the replies.\n> \n> On Monday 10 December 2007, Jakub Narebski wrote:\n> > I have noticed that your SCM comparison at \"Better SCM Initiative\"\n> > website\n> > http://better-scm.berlios.de/comparison/comparison.html\n> > misses one of the Git, version control system which is used to manage\n> > Linux kernel, and one of the main open source (distributed) version\n> > control systems (among Mercurial, Bazaar-NG, Monotone and Darcs).\n> >\n> \n> Indeed git is absent. That's because no one until you has volunteered to send \n> a patch that adds it to the comparison. Another requirement is for someone to \n> volunteer to become a \"champion\" for the version control system and maintain \n> it into the future. So who is going to be the champion?\n\nI can be git champion for \"Better SCM Initiative\" comparison... although\nI'd rather somebody else was it.\n \n[...] \n> > Below there is (slightly doctored) patch to the sources for the site.\n> >\n> \n> Despite the fact that I the comparison was recently patched to add Bazaar and \n> fix some grammatical problems, the patch still applies cleanly. However, I \n> saw that some people commented on it here. Can you send me a new patch \n> integrating all this commentary?\n\nI'll try to send revised patch soon. Integrating commentary is a bit\nharder that it could be because some responses were sent _only_ to\ngit mailing list, so I'd have to browse through git mailing list\narchives.\n\n\nBTW. some of the questions / comments were caused by the fact that the\nfeatures listed in Better SCM Initiative: Comparison are a bit ambiguous.\n\nWhat does for example \"Atomic Commit\" mean? Does it mean that if we\ninterrupt commit in the middle we would always get full commit or none,\nand not some f**d-up intermediate state? Hos CVS can have atomic commits\nthen?\n\nWhat does \"Renames Support\" mean? Does it mean that when browsing history\nwe [can] show file / directory renames? Does it mean that log of file or\ndirectory history [can] follow renames? Does it mean that line-wise file\nhistory [can] follow renames? Renames support in merges is as TODO, so\nI don't think that this one matters in this question. Because the answer,\nespecially in the case of git which is a bit different in that it does\nrename detection and not rename tracking (using inodes / file-ids),\ndepends on that...\n\n-- \nJakub Narebski\nPoland\n"},{"id":"65286","messageId":"20080114001408.GV2963@dpotapov.dyndns.org","threadId":"11226","inReplyTo":"200801130144.14574.jnareb@gmail.com","subject":"Re: Adding Git to Better SCM Initiative : Comparison","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2008-01-14T00:14:08Z","receivedAt":"2008-01-14T00:14:08Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Sun, Jan 13, 2008 at 01:44:10AM +0100, Jakub Narebski wrote:\n> \n> What does \"Renames Support\" mean? \n\nAccordingly to the clarification provided there, it means retaining the\nhistory of the file when its name changed. So I would write like this:\n\nYes. Git can automatically detects renames and show history together,\nhowever being content oriented rather than file oriented, the notion of\n\"retaining the history of the file\" can not exactly applied to it.\n\n> Because the answer,\n> especially in the case of git which is a bit different in that it does\n> rename detection and not rename tracking (using inodes / file-ids),\n> depends on that...\n\nGit is different in that it tracks the content as the whole rather than\ntracking a set of files. When you look at some source code, what you\nreally want to know who and why wrote *this*, and usually it does not\nmatter to you whether it was written in this file or another one. CVS\nis really bad at that, because if you renamed a file, it would be very\ndifficult to go back to history and find that. Many file-ids based SCMs\nhave solved this problem, however, they do not do any better than CVS\nin another very common case -- when your code is moved around as result\nof refactoring, but Git addresses both problems, not just one!\n\nSo, it is not as much about explicit renaming vs automatic, but about\ndifferent design goals. After finishing reading this questionnaire,\nit seems to me that a more proper title for it would be \"Better CVS\nInitiative\", so it is not surprisingly that Git does not fit into it\nwell. It is like trying to put characteristics of your LCD into a\nquestionnaire for CRT monitors -- some does not make sense, other\nmisleading, and most important ones are not mentioned anyway...\n\n\nDmitry\n"},{"id":"65287","messageId":"200801140131.23027.jnareb@gmail.com","threadId":"11226","inReplyTo":"20080114001408.GV2963@dpotapov.dyndns.org","subject":"Re: Adding Git to Better SCM Initiative : Comparison","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-01-14T00:31:19Z","receivedAt":"2008-01-14T00:31:19Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Mon, 14 January 2008, Dmitry Potapov wrote:\n> On Sun, Jan 13, 2008 at 01:44:10AM +0100, Jakub Narebski wrote:\n> > \n> > What does \"Renames Support\" mean? \n\nBy the way, the question was to the author of Better SCM Initiative\nComparison, Shlomi Fish.\n\n> Accordingly to the clarification provided there, it means retaining the\n> history of the file when its name changed. So I would write like this:\n> \n> Yes. Git can automatically detects renames and show history together,\n> however being content oriented rather than file oriented, the notion of\n> \"retaining the history of the file\" can not exactly applied to it.\n\n\"History of a file\" can be defined as \" log 'file'\", and this is\nwell defined also for git. And 'rename support' for file means just\nthat this history of a file (of a current file contents) follows file\nrenames.\n\nIIRC this des not work for directories... but on the other hand git,\ntracking contents only as a goal, does not track directories.\n\n> > Because the answer,\n> > especially in the case of git which is a bit different in that it does\n> > rename detection and not rename tracking (using inodes / file-ids),\n> > depends on that...\n> \n> Git is different in that it tracks the content as the whole rather than\n> tracking a set of files. When you look at some source code, what you\n> really want to know who and why wrote *this*, and usually it does not\n> matter to you whether it was written in this file or another one. CVS\n> is really bad at that, because if you renamed a file, it would be very\n> difficult to go back to history and find that. Many file-ids based SCMs\n> have solved this problem, however, they do not do any better than CVS\n> in another very common case -- when your code is moved around as result\n> of refactoring, but Git addresses both problems, not just one!\n\nAFAIK Mercurial (hg) is not file-id based, but does explicitely track\nrenames. There was even an idea presented on git mailing list to mark\nrenames in commit object in some \"note\" header.\n\n> So, it is not as much about explicit renaming vs automatic, but about\n> different design goals. After finishing reading this questionnaire,\n> it seems to me that a more proper title for it would be \"Better CVS\n> Initiative\", so it is not surprisingly that Git does not fit into it\n> well. It is like trying to put characteristics of your LCD into a\n> questionnaire for CRT monitors -- some does not make sense, other\n> misleading, and most important ones are not mentioned anyway...\n\nPlease remember that AFAIK this table is _older_ than Git itself.\nBut it is a fact that some characteristics are much patterned after\nCVS features and misfeatures.\n\nIt would be much better if for each feature there was some test\ndescribed which would allow to check if the feature is supported.\n\nBy the way, even before \"git log --follow\" you could have \"this file\nwas renamed to that file\" in the commit/revision patchset. This is\nIMHO enough of rename support. Much more important is correct support\nfor renames in merges, which is in TODO for Better-SCM comparison...\n\n-- \nJakub Narebski\nPoland\n"},{"id":"65304","messageId":"20080114065810.GY2963@dpotapov.dyndns.org","threadId":"11226","inReplyTo":"200801140131.23027.jnareb@gmail.com","subject":"Re: Adding Git to Better SCM Initiative : Comparison","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2008-01-14T06:58:10Z","receivedAt":"2008-01-14T06:58:10Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Mon, Jan 14, 2008 at 01:31:19AM +0100, Jakub Narebski wrote:\n> On Mon, 14 January 2008, Dmitry Potapov wrote:\n> \n> > Yes. Git can automatically detects renames and show history together,\n> > however being content oriented rather than file oriented, the notion of\n> > \"retaining the history of the file\" can not exactly applied to it.\n> \n> \"History of a file\" can be defined as \" log 'file'\", and this is\n> well defined also for git. \n\nYou missed the key word here -- *retaining*. In fact, if you define the\nhistory of a file just as something what \" log\" produce then what\nis the problem with CVS here? Why do most people say that CVS does not\nretain file history over rename? Certainly, you can type \"cvs old-name\"\nand see history of one file, and if you type \"cvs new-name\" then history\nof another... But somehow most people think about these two pieces as\nbeing the history of *one* file... So, your definition is incorrect or,\nat least, very different from what most people mean by that.\n\nBTW, when you type \"git log 'file'\", it shows you not history of a file,\nbut history of changes that affect the specified paths...\n\n> And 'rename support' for file means just\n> that this history of a file (of a current file contents) follows file\n> renames.\n\nTo equate a file with its contents is like to equate a variable with\nits value. They are not exactly the same. If you renamed a file and\ncompletely changed its contents, is it still the same file or not?\nIf you think about file as being inode then the answer is yes, but if\nlook at its content then the answer is no.\n\nGit tracks contents, while many other SCMs tracks files regardless of\ntheir contents. So, Git can show the history of file contents, but\nnot the history of a file...\n\n> \n> IIRC this des not work for directories... \n\nGit works for directories, it is just that the --follow option cannot\napplied to it, because this option means to follow the file contents,\nwhich does not make much sense for directories.\n\n> but on the other hand git,\n> tracking contents only as a goal, does not track directories.\n\nExactly.\n\n> > \n> > Git is different in that it tracks the content as the whole rather than\n> > tracking a set of files. When you look at some source code, what you\n> > really want to know who and why wrote *this*, and usually it does not\n> > matter to you whether it was written in this file or another one. CVS\n> > is really bad at that, because if you renamed a file, it would be very\n> > difficult to go back to history and find that. Many file-ids based SCMs\n> > have solved this problem, however, they do not do any better than CVS\n> > in another very common case -- when your code is moved around as result\n> > of refactoring, but Git addresses both problems, not just one!\n> \n> AFAIK Mercurial (hg) is not file-id based, but does explicitely track\n> renames. There was even an idea presented on git mailing list to mark\n> renames in commit object in some \"note\" header.\n\nI suspect the main reason why Mercurial support that is that a lot of\nprogrammers whose mind was mangled by many years of CVS experience asked\nfor that feature. In practice, what you really want to track is contents.\nAnd it is not difficult to add some \"note\" to the commit and teach Git to\nfollow it, but I don't see any practical value in that...\n\n> > So, it is not as much about explicit renaming vs automatic, but about\n> > different design goals. After finishing reading this questionnaire,\n> > it seems to me that a more proper title for it would be \"Better CVS\n> > Initiative\", so it is not surprisingly that Git does not fit into it\n> > well. It is like trying to put characteristics of your LCD into a\n> > questionnaire for CRT monitors -- some does not make sense, other\n> > misleading, and most important ones are not mentioned anyway...\n> \n> Please remember that AFAIK this table is _older_ than Git itself.\n> But it is a fact that some characteristics are much patterned after\n> CVS features and misfeatures.\n\nWell, if it is so old, that explains why it gave me such impression...\n\n> \n> It would be much better if for each feature there was some test\n> described which would allow to check if the feature is supported.\n\nWanna test your LCD monitor with some old CRT tests? -:)\n\n> \n> By the way, even before \"git log --follow\" you could have \"this file\n> was renamed to that file\" in the commit/revision patchset. \n\nYou could write that in CVS message too, but I don't think it can\nbe considered as retaining the history of the file...\n\n\nDmitry\n"},{"id":"65315","messageId":"200801141314.21686.jnareb@gmail.com","threadId":"11226","inReplyTo":"20080114065810.GY2963@dpotapov.dyndns.org","subject":"Re: Adding Git to Better SCM Initiative : Comparison","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-01-14T12:14:20Z","receivedAt":"2008-01-14T12:14:20Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Dnia poniedziałek 14. stycznia 2008 07:58, Dmitry Potapov napisał:\n> On Mon, Jan 14, 2008 at 01:31:19AM +0100, Jakub Narebski wrote:\n> > On Mon, 14 January 2008, Dmitry Potapov wrote:\n> > \n> > > Yes. Git can automatically detects renames and show history together,\n> > > however being content oriented rather than file oriented, the notion of\n> > > \"retaining the history of the file\" can not exactly applied to it.\n> > \n> > \"History of a file\" can be defined as \" log 'file'\", and this is\n> > well defined also for git. \n> \n> You missed the key word here -- *retaining*. In fact, if you define the\n> history of a file just as something what \" log\" produce then what\n> is the problem with CVS here? Why do most people say that CVS does not\n> retain file history over rename? Certainly, you can type \"cvs old-name\"\n> and see history of one file, and if you type \"cvs new-name\" then history\n> of another... But somehow most people think about these two pieces as\n> being the history of *one* file... So, your definition is incorrect or,\n> at least, very different from what most people mean by that.\n\nI assume that 0th part of rename support is true, i.e. that we can\nrecover previous full-tree state of repository.\n\n> BTW, when you type \"git log 'file'\", it shows you not history of a file,\n> but history of changes that affect the specified paths...\n\nThe fact that in \"git log \" the part is path _limiter_\n(and can be directory, or set of directories) rather than being limited\nto simply single filename is what makes git different, both in good\n(\"git log subsystem/path\") and in bad (different from what other SCM\nused to) way.\n\nWhen you type \"git log --follow='file'\", it shows you history of\na _contents_ which currently is in 'file'; even if there were rename\nin the history of 'file' somewhere in the past.\n\nWhen you type \"git log 'directory'\", it shows you (simplified) history\nof changes affesting specified directory (usually some subsystem).\n\n\nIMHO \"rename support\" should be defined as\n1.) showing renames when examining given revision (status, log, show;\n whatever it is called).\n2.) it should be able to follow history of a file when it looks like\n this: add, change, rename, change.\n\n> > And 'rename support' for file means just\n> > that this history of a file (of a current file contents) follows file\n> > renames.\n[...]\n> > \n> > IIRC this des not work for directories... \n> \n> Git works for directories, it is just that the --follow option cannot\n> applied to it, because this option means to follow the file contents,\n> which does not make much sense for directories.\n\nBut it would be nice to have somehow \"git log --follow=directory\" work,\neven if directory in which susystem resides was renamed. It is harder\nwork also because (I think) directories are more often split and joined\nthan file[s contents].\n\n> > > Git is different in that it tracks the content as the whole rather than\n> > > tracking a set of files. When you look at some source code, what you\n> > > really want to know who and why wrote *this*, and usually it does not\n> > > matter to you whether it was written in this file or another one. CVS\n> > > is really bad at that, because if you renamed a file, it would be very\n> > > difficult to go back to history and find that. Many file-ids based SCMs\n> > > have solved this problem, however, they do not do any better than CVS\n> > > in another very common case -- when your code is moved around as result\n> > > of refactoring, but Git addresses both problems, not just one!\n> > \n> > AFAIK Mercurial (hg) is not file-id based, but does explicitely track\n> > renames. There was even an idea presented on git mailing list to mark\n> > renames in commit object in some \"note\" header.\n> \n> I suspect the main reason why Mercurial support that is that a lot of\n> programmers whose mind was mangled by many years of CVS experience asked\n> for that feature. In practice, what you really want to track is contents.\n> And it is not difficult to add some \"note\" to the commit and teach Git to\n> follow it, but I don't see any practical value in that...\n\nMercurial can be IMHO from architecture point of view be viewed a bit\nas \"CVS done right\", much more than Subversion, with its path-hashed\nchangeset storage, manifest file, and changelog / changerev file.\n\nAnd I guess that Mercurial supports this because of the most important\npart of \"renames support\" (which is present only as TODO for Better-SCM\ncomparison), namely merging correct files in presence of renames.\n \n> > \n> > It would be much better if for each feature there was some test\n> > described which would allow to check if the feature is supported.\n> \n> Wanna test your LCD monitor with some old CRT tests? -:)\n\nIf those tests were done correctly, not from technical side (\"renames\nsupport\" and other similar thingies for SCMs, refresh rate for LCD/CRT),\nbut from user side (does command which shows history of a file follows\nrenames, eyestrain / image sharpness for monitors).... :-)\n\n-- \nJakub Narebski\nPoland\n"}]}