* Adding Git to Better SCM Initiative : Comparison
@ 2007-11-28 22:39 Jakub Narebski
2007-11-29 1:48 ` Robin Rosenberg
` (2 more replies)
0 siblings, 3 replies; 33+ messages in thread
From: Jakub Narebski @ 2007-11-28 22:39 UTC (permalink / raw)
To: git
I'd like to add Git to comparison table of SCMs at Better SCM
Initiative site:
http://better-scm.berlios.de
To do that, I need to fill in infomration about Git. Most
of questions / items didn't give much problem, but there
are a few on which I would like your input.
(Yes, I know that such SCM comparisons are usually biased towards the
idea of what are most important features of a version control system.
Nevertheless...)
1. Ease of Deployment
How easy it is to deploy the software? What are
the depenedencies and how can they be satisfied?
There are binary packages for Linux (RPM, deb) and for MS Windows
(msysGit). Git requires POSIX shell, Perl, and POSIX utilities
(BTW. INSTALL file lacks full specification of dependences); although
there is ongoing effort towards making all commands builtin, in C.
Makefile contains ready configuration for many OS, and there is
autoconf script to generate Makefile configuration.
I'm not sure if the problems with compiling documentation to HTML and
manpage forms, which require AsciiDoc and xmlto toolchains should be
also mentioned here. Well, that and the fact that there exist
pre-build documentation in html and man forms.
2. Command Set
What is the command set? How compatible it is with
the commands of CVS (the current open-source defacto
standard)?
Should it be: "Tries to follow CVS conventions, but deviates where
there is a different design.", as for Mercurial and Monotone?
If I remember correctly command set is patterned somewhat after
BitKeeper.
"Large command set divided into plumbing (low lewel, to be used in
scripts) and porcelain (high level commands)."
3. Portability
How portable is the version-control system to various
operating systems, computer architectures, and other
types of systems?
"Good. Portable across all POSIX systems.
There exists Win32 binary using MinGW."
>From the results of Git User's Surveys there are many OS on which Git
is used; but it doesn't tell us how hard was to deply Git on those
exotic operatings systems.
4. Repository Permissions
Is it possible to define permissions on access to different
parts of a remote repository? Or is access open for all?
"Partial (?). It is possible to lock down repository
(access to branches and tags) using hooks."
I don't know if it is possible to do finer level ACLs, i.e. if it
is possible to lock subdirectories or files in Git. Although for
distributed SCMs ACL doesn't matter much: check diffstat and merge or
not from trusted people. We have "network of trust" (BTW. Karl Fogel
in OSSBook recommends 'soft' control of access control to repository,
on social rather than on technical level).
P.S. How do "svn diff" looks like?
--
Jakub Narebski
Poland
^ permalink raw reply [flat|nested] 33+ messages in thread* Re: Adding Git to Better SCM Initiative : Comparison
2007-11-28 22:39 Adding Git to Better SCM Initiative : Comparison Jakub Narebski
@ 2007-11-29 1:48 ` Robin Rosenberg
2007-11-29 7:17 ` Jan Hudec
2007-11-29 2:26 ` Jakub Narebski
2007-12-03 19:57 ` Jakub Narebski
2 siblings, 1 reply; 33+ messages in thread
From: Robin Rosenberg @ 2007-11-29 1:48 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
onsdag 28 november 2007 skrev Jakub Narebski:
> I'd like to add Git to comparison table of SCMs at Better SCM
> Initiative site:
> http://better-scm.berlios.de
>
> To do that, I need to fill in infomration about Git. Most
> of questions / items didn't give much problem, but there
> are a few on which I would like your input.
>
> (Yes, I know that such SCM comparisons are usually biased towards the
> idea of what are most important features of a version control system.
> Nevertheless...)
[...]
> 4. Repository Permissions
>
> Is it possible to define permissions on access to different
> parts of a remote repository? Or is access open for all?
>
> "Partial (?). It is possible to lock down repository
> (access to branches and tags) using hooks."
>
> I don't know if it is possible to do finer level ACLs, i.e. if it
> is possible to lock subdirectories or files in Git. Although for
> distributed SCMs ACL doesn't matter much: check diffstat and merge or
> not from trusted people. We have "network of trust" (BTW. Karl Fogel
> in OSSBook recommends 'soft' control of access control to repository,
> on social rather than on technical level).
I think what is most interesting here is access to content for which git has
just about nothing worth mentioning, Just admit it. "Truth in advertising".
I did start doing this so here's my version (pre-msysgit). Please try to bring up the defintion
of "atomic" again with the author. I did complain a little but nothing happened. The issue is
that Clearcase is listed as having "atomic" commits which is not true for any usable definition
of atomic in SCM context. With the definition in use there I think CVS should be considered
having atomic commits too, at least I've never seen a half-committed file there.
% svn diff
Index: src/comparison/scm-comparison.xml
===================================================================
--- src/comparison/scm-comparison.xml (revision 290)
+++ src/comparison/scm-comparison.xml (arbetskopia)
@@ -71,6 +71,9 @@
<impl id="ls-sync">
<name>LibreSource Synchronizer</name>
</impl>
+ <impl id="git">
+ <name>Git</name>
+ </impl>
</implementations>
<timestamp>
$Id$
@@ -182,6 +185,13 @@
needs to be up-to-date before doing a rename/move operation.
This operation will be committed directly.
</s>
+ <s id="git">
+ Yes (or no depending on interpretation). Git typically detects
+ renames and copies based on content regardless of whether the
+ committer indicated the fact. The detection is content based
+ rather than file-id based. There is explicit rename too, but
+ it is not used much.
+ </s>
</compare>
</section>
<section id="copy">
@@ -236,6 +246,10 @@
limitations in Windows environments)
</s>
<s id="ls-sync">No, copies will start there own history.</s>
+ <s id="git">Yes(or no depending on interpretation). Git detects
+ copies and moves based on content. It does not track
+ history on a file-id based scheme.
+ </s>
</compare>
</section>
<section id="repos_clone">
@@ -288,6 +302,11 @@
Yes, but is not documented and its based on the dataflow feature of the
LibreSource Synchronizer.
</s>
+ <s id="git">
+ Yes. This is a fundamental part of using Git. A Git user typically always
+ has a full copy of the entire repostory (well compressed) that is initialized
+ using a clone command.
+ </s>
</compare>
</section>
<section id="push">
@@ -331,6 +350,7 @@
<s id="cmsynergy">Yes, as long as you have the (more expensive) Distributed package.</s>
<s id="clearcase">Yes, using Clearcase Multisite.</s>
<s id="ls-sync">Yes, it's what we call a dataflow.</s>
+ <s id="git">Yes. This is a fundamental part of using Git.</s>
</compare>
</section>
<section id="permissions">
@@ -417,7 +437,8 @@
multi-platform environments.
</s>
<s id="ls-sync">Permissions are set for the whole repository or branch.</s>
- </compare>
+ <s id="git">No, but bad changes can be reverted before they are published.</s>
+ </compare>
</section>
<section id="changesets">
<title>Changesets' Support</title>
@@ -490,6 +511,11 @@
Partial support. There are implicit changeset that are generated on
each commit.
</s>
+ <s id="git">Yes. Actually Git is snapshot based which means Git records
+ the full state in every commit, which means that any two
+ commits can be compared directly very quickly, although the
+ repository is typically browsed as a series of change sets.
+ </s>
</compare>
</section>
<section id="annotate">
@@ -534,6 +560,9 @@
Yes locally without any server connection with the standard graphical
Java client.
</s>
+ <s id="git">Yes. It can also detect the origin of copied and moved source
+ lines.
+ </s>
</compare>
</section>
</section>
@@ -610,6 +639,12 @@
It is possible to commit only a certain directory. However, one must
check out the entire repository as a whole.
</s>
+ <s id="git">No. However it is possible to commit only selected
+ changes in the working tree rather than everything. Subproject
+ support makes it possible to split large projects into several
+ repositories and link them. Related repositories need not be
+ checked out or cloned.
+ </s>
</compare>
</section>
<section id="tracking_uncommited_changes">
@@ -659,6 +694,10 @@
Yes, with the Synchronizer Studio (default Java client) or with the
standard diff command (diff -r . .so6/xxx/REFCOPY/)
</s>
+ <s id="git">Yes. In addition commits are local and will not be seen
+ until he/she decides to publish them making it possible to
+ track multiple versions locally before publishing.
+ </s>
</compare>
</section>
<section id="per_file_commit_messages">
@@ -714,6 +753,7 @@
for a per-changeset message.
</s>
<s id="ls-sync">No. Commit messages are per changeset.</s>
+ <s id="git">No. The same message applies the the commit as a whole.</s>
</compare>
</section>
</section>
@@ -828,6 +868,11 @@
documentation. Installing and getting started with the GUI is very easy
though. (update/commit-next-next-next-finished)
</s>
+ <s id="git">
+ There a good tutorials manual pages and a supportive community.
+ Basic usage is simple, but advanced usage requires understanding of
+ what makes git different.
+ </s>
</compare>
</section>
<section id="ease_of_deployment">
@@ -950,6 +995,10 @@
LibreSource repository web page.
(links: create workspace, update, commit, studio...)
</s>
+ <s id="git">
+ Very simple to deploy on Unix-like systems. Windows installs
+ is not fully developed yet. Installing in cygwin is simple though.
+ </s>
</compare>
</section>
<section id="command_set">
@@ -1048,6 +1097,13 @@
Basic commands available (commit/update), but it's really simple to
use the GUI. Ant task are also available.
</s>
+ <s id="git">Basic usage could be considered similar, but trying
+ to use Git like CVS would be counterproductive since many
+ cases of CVS usage is by design not possible in Git. The
+ number of command is large. ~140 but only ~20 commands
+ are typically used and less than ten will do for casual
+ users.
+ </s>
</compare>
</section>
<section id="networking">
@@ -1152,6 +1208,13 @@
<s id="ls-sync">
Good. Use of HTTP to get through firwalls.
</s>
+ <s id="git">
+ Excellent. Normal usage is off-line, but networking is
+ used for sharing changes Networking including ssh,
+ a special git protocol http and mail can be used to share
+ changes, both incoming and outgoing. Mail can be used
+ via IMAP and mbox files.
+ </s>
</compare>
</section>
<section id="portability">
@@ -1249,6 +1312,11 @@
Excellent. Clients and servers work on any Java 1.5-compatible
platform. (Windows, Linux and Mac OS X )
</s>
+ <s id="git">
+ Very good for POSIX compatible environments. A non-cygwin
+ port for windows is underway. There are some graphical
+ tools available for windows in cygwin.
+ </s>
</compare>
</section>
</section>
@@ -1323,6 +1391,7 @@
Yes, without diff features but with a better awareness support.
(allow to know at any time on each version each one is working on)
</s>
+ <s id="git">Yes. gitweb</s>
</compare>
</section>
<section id="availability_of_guis">
@@ -1421,6 +1490,10 @@
is automatically launched from the repository web page and
another one which is an Eclipse plugin.
</s>
+ <s id="git">
+ A number of good GUI's are availble for basic usage,
+ but typical usage is command based.
+ </s>
</compare>
</section>
</section>
@@ -1501,7 +1574,8 @@
additional licensing.
</s>
<s id="ls-sync">QPL - The Qt Public License (OpenSource)</s>
- </compare>
+ <s id="git">GPL</s>
+ </compare>
</section>
</section>
</contents>
-- robin
^ permalink raw reply [flat|nested] 33+ messages in thread* Re: Adding Git to Better SCM Initiative : Comparison
2007-11-29 1:48 ` Robin Rosenberg
@ 2007-11-29 7:17 ` Jan Hudec
0 siblings, 0 replies; 33+ messages in thread
From: Jan Hudec @ 2007-11-29 7:17 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Jakub Narebski, git
On Thu, Nov 29, 2007 at 02:48:22 +0100, Robin Rosenberg wrote:
> I did start doing this so here's my version (pre-msysgit). Please try to bring up the defintion
> of "atomic" again with the author. I did complain a little but nothing happened. The issue is
> that Clearcase is listed as having "atomic" commits which is not true for any usable definition
> of atomic in SCM context. With the definition in use there I think CVS should be considered
> having atomic commits too, at least I've never seen a half-committed file there.
Actually, I did. Or rather, I did see a commit, that didn't make it to the
server, but the client thought it did!
Maybe instead of asking the author to change the definition of atomic, ask
him to add an item for whole-tree commits. That more precisely describes what
is the point.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Adding Git to Better SCM Initiative : Comparison
2007-11-28 22:39 Adding Git to Better SCM Initiative : Comparison Jakub Narebski
2007-11-29 1:48 ` Robin Rosenberg
@ 2007-11-29 2:26 ` Jakub Narebski
2007-11-29 20:07 ` Alex Riesen
2007-12-03 19:57 ` Jakub Narebski
2 siblings, 1 reply; 33+ messages in thread
From: Jakub Narebski @ 2007-11-29 2:26 UTC (permalink / raw)
To: git; +Cc: Robin Rosenberg
Jakub Narebski wrote:
> To do that, I need to fill in information about Git. Most
> of questions / items didn't give much problem, but there
> are a few on which I would like your input.
By the way, below is patch with the information I have filled.
Check out the TO DO items.
diff --git a/src/comparison/scm-comparison.xml b/src/comparison/scm-comparison.xml
index b459747..6f84190 100644
--- a/src/comparison/scm-comparison.xml
+++ b/src/comparison/scm-comparison.xml
@@ -38,6 +38,9 @@ TODO:
<impl id="darcs">
<name>Darcs</name>
</impl>
+ <impl id="git">
+ <name>Git</name>
+ </impl>
<impl id="mercurial">
<name>Mercurial</name>
</impl>
@@ -106,6 +109,7 @@ TODO:
<s id="svk">Commits are atomic.</s>
<s id="aegis">Commits are atomic.</s>
<s id="bitkeeper">Yes (but need to verify)</s>
+ <s id="git">Yes.</s>
<s id="mercurial">Yes.</s>
<s id="monotone">Yes.</s>
<s id="opencm">Yes. Commits are atomic.</s>
@@ -142,6 +146,11 @@ TODO:
<s id="darcs">Yes. Renames are supported.</s>
<s id="bitkeeper">Yes. Renames are supported.</s>
<s id="aegis">Yes. Renames are supported.</s>
+ <s id="git">
+ N/A. Git does not track renames, but detects renames
+ and copies. You can follow history of file using
+ 'git log --follow'.
+ </s>
<s id="mercurial">Yes. Renames are supported.</s>
<s id="monotone">Yes. Renames are supported.</s>
<s id="opencm">Yes. Renames are supported</s>
@@ -214,6 +223,11 @@ TODO:
Yes. Copies are supported.
</s>
<s id="aegis">No. Copies are not supported.</s>
+ <s id="git">
+ N/A. Git does not track copies, but detects renames
+ and copies. You can follow history of file using
+ 'git log -C --follow'.
+ </s>
<s id="mercurial">Yes. Copies are supported</s>
<s id="monotone">Yes. Copies are supported</s>
<s id="opencm">No. Copies are not supported.</s>
@@ -267,6 +281,7 @@ TODO:
<s id="darcs">Yes.</s>
<s id="bitkeeper">Yes.</s>
<s id="aegis">Yes.</s>
+ <s id="git">Yes.</s>
<s id="mercurial">Yes.</s>
<s id="monotone">Yes.</s>
<s id="opencm">No.</s>
@@ -313,6 +328,7 @@ TODO:
<s id="darcs">Yes.</s>
<s id="bitkeeper">Yes.</s>
<s id="aegis">Yes.</s>
+ <s id="git">Yes.</s>
<s id="mercurial">Yes.</s>
<s id="monotone">Yes.</s>
<s id="opencm">No.</s>
@@ -373,6 +389,10 @@ TODO:
<s id="svk">
Same as subversion.
</s>
+ <s id="git">
+ Partial (?). It is possible to lock down repository
+ (access to branches and tags) using hooks.
+ </s>
<s id="mercurial">
Yes. It is possible to lock down repositories,
subdirectories, or files using hooks.
@@ -455,6 +475,9 @@ TODO:
<s id="darcs">
Yes. Changesets are supported.
</s>
+ <s id="git">
+ Yes. Changesets are supported.
+ </s>
<s id="mercurial">
Yes. Changesets are supported.
</s>
@@ -509,6 +532,7 @@ TODO:
<s id="arch">Not in the command line client, but ViewARCH,
a web-interface for Arch, has it.</s>
<s id="darcs">Yes. (darcs annotate)</s>
+ <s id="git">Yes. (git blame, git gui blame)</s>
<s id="mercurial">Yes. (hg annotate)</s>
<s id="monotone">Yes, as of version 0.19.</s>
<s id="aegis">Yes. aeannotate</s>
@@ -570,6 +594,9 @@ TODO:
whole.
</s>
<s id="aegis">No. All changes are made repository-wide.</s>
+ <s id="git">
+ No. All changes are made repository-wide.
+ But you can use submodules / subrpoject support for that.</s>
<s id="mercurial">
It is possible to commit changes only in a subset of the
tree. There are plans for partial checkouts.
@@ -636,6 +663,10 @@ TODO:
Yes, using "darcs whatsnew".
</s>
<s id="aegis">Yes. Using aediff</s>
+ <s id="git">
+ Yes. Using git diff.
+ Note that git uses staging area for commits (index).
+ </s>
<s id="mercurial">Yes. Using hg diff.</s>
<s id="monotone">Yes. In a similar fashion to CVS.</s>
<s id="opencm">Yes. Using cm diff</s>
@@ -681,6 +712,10 @@ TODO:
<s id="darcs">
No.
</s>
+ <s id="git">
+ No. But you can tag (with description) given contents
+ of a file (blob).
+ </s>
<s id="mercurial">
No.
</s>
@@ -782,6 +817,15 @@ TODO:
and the client contains a help tool that offers
an integrated help system.
</s>
+ <s id="git">
+ Medium. There's Git User's Manual, manpages, some
+ technical documentation and some howtos. All
+ documentation is also available online in HTML format;
+ there is additional information (including beginnings
+ of FAQ) on git wiki.
+ Nevertheles one of complaints in surveys is insufficient
+ or fragmented documentation.
+ </s>
<s id="mercurial">
Very good. There's an overview and tutorial on the
web site, and integrated help for every command.
@@ -894,6 +938,14 @@ TODO:
to install the subversion perl bindings and a few modules
from CPAN.
</s>
+ <s id="git">
+ TO DO. RPMs and deb packages for Linux. msysGit and
+ Cygwin for Win32 - Git requires POSIX shell, Perl,
+ and POSIX utilities for some commands (builtin).
+ Autoconf to generate Makefile configuration; ready
+ generic configuration for many OS. Compiling docs
+ requires asciidoc and xmlto toolchain, but prebuild.
+ </s>
<s id="mercurial">
Excellent. Binary packages are available for all
popular platforms. Building from source requires
@@ -1006,6 +1058,13 @@ TODO:
but since the model is different most commands are
unique.
</s>
+ <s id="git">
+ TO DO.
+ Tries to follow CVS conventions, but deviates where there
+ is a different design.
+ Large command set divided into plumbing (low lewel, to be
+ used in scripts) and porcelain (high level).
+ </s>
<s id="mercurial">
Tries to follow CVS conventions, but deviates where there
is a different design.
@@ -1106,6 +1165,10 @@ TODO:
There exists some HTTP-functionality, but it is quite
limited.
</s>
+ <s id="git">
+ Good. Uses HTTPS (with WebDAV) or ssh for push,
+ HTTP, FTP, ssh or custom protocol for fetch.
+ </s>
<s id="mercurial">
Excellent. Uses HTTP or ssh. Remote access also
works safely without locks over read-only network
@@ -1203,6 +1266,10 @@ TODO:
Very good. Supports many UNIXes, Mac OS X, and Windows,
and is written in a portable language.
</s>
+ <s id="git">TO DO.
+ Good. Portable across all POSIX systems.
+ There exists Win32 binary using MinGW.
+ </s>
<s id="mercurial">
Excellent. Runs on all platforms supported by
Python. Repositories are portable across CPU
@@ -1300,6 +1367,9 @@ TODO:
is included in the distribution.
</s>
<s id="aegis">Yes.</s>
+ <s id="git">
+ Yes. The web interface is a bundled component.
+ Other web interfaces: cgit, wit, git-php</s>
<s id="mercurial">Yes. The web interface is a bundled component.</s>
<s id="monotone">No.</s>
<s id="opencm">No.</s>
@@ -1373,6 +1443,11 @@ TODO:
<s id="aegis">
There is tkaegis.
</s>
+ <s id="git">RO DO
+ Bundled history viewer gitk and commit tool git-gui,
+ both use Tcl/Tk. There is also qgit (Qt) and Giggle
+ (GTK+).
+ </s>
<s id="mercurial">
History viewing available with hgit extension;
check-in extension (hgct) makes committing easier.
@@ -1453,6 +1528,7 @@ TODO:
GNU GPL (open-source)
</s>
<s id="svk">Perl License. (open source)</s>
+ <s id="git">GNU GPL (open source)</s>
<s id="mercurial">GNU GPL (open source)</s>
<s id="monotone">GNU GPL (open source)</s>
<s id="opencm">
--
Jakub Narebski
Poland
^ permalink raw reply related [flat|nested] 33+ messages in thread* Re: Adding Git to Better SCM Initiative : Comparison
2007-11-29 2:26 ` Jakub Narebski
@ 2007-11-29 20:07 ` Alex Riesen
2007-11-30 0:18 ` Jakub Narebski
2007-11-30 18:34 ` Jan Hudec
0 siblings, 2 replies; 33+ messages in thread
From: Alex Riesen @ 2007-11-29 20:07 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Robin Rosenberg
Jakub Narebski, Thu, Nov 29, 2007 03:26:12 +0100:
> + <s id="git">
> + Medium. There's Git User's Manual, manpages, some
> + technical documentation and some howtos. All
> + documentation is also available online in HTML format;
> + there is additional information (including beginnings
> + of FAQ) on git wiki.
> + Nevertheles one of complaints in surveys is insufficient
"Nevertheless" (two "s").
BTW, I wouldn't call the level of documentation "Medium" when compared
to any commercial SCM. How can they earn more than "a little", when
compared to any opensource program?
> @@ -894,6 +938,14 @@ TODO:
> to install the subversion perl bindings and a few modules
> from CPAN.
> </s>
> + <s id="git">
> + TO DO. RPMs and deb packages for Linux. msysGit and
> + Cygwin for Win32 - Git requires POSIX shell, Perl,
> + and POSIX utilities for some commands (builtin).
I read this as: "Git requires all these programs for builtin
commands". Which is a bit confusing. Just drop "(builtin)"?
> + Autoconf to generate Makefile configuration; ready
> + generic configuration for many OS. Compiling docs
> + requires asciidoc and xmlto toolchain, but prebuild.
"prebuilt" (with "t"). Maybe remove ", but prebuilt" completely?
> @@ -1106,6 +1165,10 @@ TODO:
> There exists some HTTP-functionality, but it is quite
> limited.
> </s>
> + <s id="git">
> + Good. Uses HTTPS (with WebDAV) or ssh for push,
> + HTTP, FTP, ssh or custom protocol for fetch.
> + </s>
You forgot bundles (aka SneakerNet).
Again, compared to everyone else it is "vastly superior" :)
> <s id="mercurial">
> Excellent. Uses HTTP or ssh. Remote access also
> works safely without locks over read-only network
> @@ -1203,6 +1266,10 @@ TODO:
> Very good. Supports many UNIXes, Mac OS X, and Windows,
> and is written in a portable language.
> </s>
> + <s id="git">TO DO.
> + Good. Portable across all POSIX systems.
> + There exists Win32 binary using MinGW.
> + </s>
"binaries": MinGW and Cygwin. And it is definitely "excellent" by the
standards of the site.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Adding Git to Better SCM Initiative : Comparison
2007-11-29 20:07 ` Alex Riesen
@ 2007-11-30 0:18 ` Jakub Narebski
2007-11-30 1:26 ` Johan Herland
2007-11-30 7:16 ` Alex Riesen
2007-11-30 18:34 ` Jan Hudec
1 sibling, 2 replies; 33+ messages in thread
From: Jakub Narebski @ 2007-11-30 0:18 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Robin Rosenberg
On Thu, 29 Nov 2007, Alex Riesen wrote:
> Jakub Narebski, Thu, Nov 29, 2007 03:26:12 +0100:
>> + <s id="git">
>> + Medium. There's Git User's Manual, manpages, some
>> + technical documentation and some howtos. All
>> + documentation is also available online in HTML format;
>> + there is additional information (including beginnings
>> + of FAQ) on git wiki.
>> + Nevertheles one of complaints in surveys is insufficient
>
> "Nevertheless" (two "s").
>
> BTW, I wouldn't call the level of documentation "Medium" when compared
> to any commercial SCM. How can they earn more than "a little", when
> compared to any opensource program?
Source code is not [user level] documentation.
But perhaps it should be "Good" instead of "Medium", although I think
not "Excellent".
>> @@ -894,6 +938,14 @@ TODO:
>> to install the subversion perl bindings and a few modules
>> from CPAN.
>> </s>
>> + <s id="git">
>> + TO DO. RPMs and deb packages for Linux. msysGit and
>> + Cygwin for Win32 - Git requires POSIX shell, Perl,
>> + and POSIX utilities for some commands (builtin).
>
> I read this as: "Git requires all these programs for builtin
> commands". Which is a bit confusing. Just drop "(builtin)"?
What I meant to say that some Git commands are scripts in Perl or POSIX
shell, and that those Git commands requires POSIX utilities (which of
those utilities are needed is unfortunately not mentioned explicitely
in the INSTALL file); _but_ that there is ongoing effort to rewrite
matured commands in C (as built-ins).
But this is perhaps too long explanation to put it in this comparison
table.
>> + Autoconf to generate Makefile configuration; ready
>> + generic configuration for many OS. Compiling docs
>> + requires asciidoc and xmlto toolchain, but prebuild.
>
> "prebuilt" (with "t"). Maybe remove ", but prebuilt" completely?
Gaaah, it should be "but you can get prebuilt docs".
>> @@ -1106,6 +1165,10 @@ TODO:
>> There exists some HTTP-functionality, but it is quite
>> limited.
>> </s>
>> + <s id="git">
>> + Good. Uses HTTPS (with WebDAV) or ssh for push,
>> + HTTP, FTP, ssh or custom protocol for fetch.
>> + </s>
>
> You forgot bundles (aka SneakerNet).
> Again, compared to everyone else it is "vastly superior" :)
Bundles and patches (peer review!) I think truly move it from "Good"
to "Excellent".
>> <s id="mercurial">
>> Excellent. Uses HTTP or ssh. Remote access also
>> works safely without locks over read-only network
By the way, can Git be used with repository on lockless network
filesystem? (Although with distributed SCM it perhaps be better
to just use many distributed repositories...). How does it work
with repository available via SMBFS / CIFS or NFS?
>> @@ -1203,6 +1266,10 @@ TODO:
>> Very good. Supports many UNIXes, Mac OS X, and Windows,
>> and is written in a portable language.
>> </s>
>> + <s id="git">TO DO.
>> + Good. Portable across all POSIX systems.
>> + There exists Win32 binary using MinGW.
>> + </s>
>
> "binaries": MinGW and Cygwin. And it is definitely "excellent" by the
> standards of the site.
I'd say excellent on POSIX systems, good on Win32 (there are still
as far as I remember some troubles). I hope that gitbox project would
succeed, and one would need only single binary (plus perhaps wish for
GUI, and DLLs) to use git on MS Windows.
--
Jakub Narebski
Poland
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Adding Git to Better SCM Initiative : Comparison
2007-11-30 0:18 ` Jakub Narebski
@ 2007-11-30 1:26 ` Johan Herland
2007-11-30 1:53 ` Jakub Narebski
2007-11-30 7:16 ` Alex Riesen
1 sibling, 1 reply; 33+ messages in thread
From: Johan Herland @ 2007-11-30 1:26 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Alex Riesen, Robin Rosenberg
On Friday 30 November 2007, Jakub Narebski wrote:
> On Thu, 29 Nov 2007, Alex Riesen wrote:
> > Jakub Narebski, Thu, Nov 29, 2007 03:26:12 +0100:
>
> >> + <s id="git">
> >> + Medium. There's Git User's Manual, manpages, some
> >> + technical documentation and some howtos. All
> >> + documentation is also available online in HTML format;
> >> + there is additional information (including beginnings
> >> + of FAQ) on git wiki.
> >> + Nevertheles one of complaints in surveys is insufficient
> >
> > "Nevertheless" (two "s").
> >
> > BTW, I wouldn't call the level of documentation "Medium" when compared
> > to any commercial SCM. How can they earn more than "a little", when
> > compared to any opensource program?
>
> Source code is not [user level] documentation.
>
> But perhaps it should be "Good" instead of "Medium", although I think
> not "Excellent".
If we try to compare ourselves to what's closest, i.e. Mercurial, I would
say that Git's documentation is probably on par with what Mercurial has to
offer. Their "Documentation" entry in the comparison is as follows:
"Very good. There's an overview and tutorial on the web site, and integrated
help for every command."
I say we go for something similar.
Have fun!
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Adding Git to Better SCM Initiative : Comparison
2007-11-30 1:26 ` Johan Herland
@ 2007-11-30 1:53 ` Jakub Narebski
0 siblings, 0 replies; 33+ messages in thread
From: Jakub Narebski @ 2007-11-30 1:53 UTC (permalink / raw)
To: Johan Herland; +Cc: git, Alex Riesen, Robin Rosenberg
On Fri, 30 Nov 2007, Johan Herland wrote:
> On Friday 30 November 2007, Jakub Narebski wrote:
>> On Thu, 29 Nov 2007, Alex Riesen wrote:
>>> Jakub Narebski, Thu, Nov 29, 2007 03:26:12 +0100:
>>
>>>> + <s id="git">
>>>> + Medium. There's Git User's Manual, manpages, some
>>>> + technical documentation and some howtos. All
>>>> + documentation is also available online in HTML format;
>>>> + there is additional information (including beginnings
>>>> + of FAQ) on git wiki.
>>>> + Nevertheles one of complaints in surveys is insufficient
>>>
>>> "Nevertheless" (two "s").
>>>
>>> BTW, I wouldn't call the level of documentation "Medium" when compared
>>> to any commercial SCM. How can they earn more than "a little", when
>>> compared to any opensource program?
>>
>> Source code is not [user level] documentation.
>>
>> But perhaps it should be "Good" instead of "Medium", although I think
>> not "Excellent".
>
> If we try to compare ourselves to what's closest, i.e. Mercurial, I would
> say that Git's documentation is probably on par with what Mercurial has to
> offer. Their "Documentation" entry in the comparison is as follows:
>
> "Very good. There's an overview and tutorial on the web site, and integrated
> help for every command."
>
> I say we go for something similar.
Well, at least according to surveys results people perceive
"The Mercurial Book" (hgbook) as better documentation than
"Git User's Manual" + tutorials. See for example frequent requests
for "The Git Book" patterned after hgbook and/or svnbook.
BTW. the list was meant to be updated by contributors who added
SCMs, but it doesn't liik lik it is...
--
Jakub Narebski
Poland
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Adding Git to Better SCM Initiative : Comparison
2007-11-30 0:18 ` Jakub Narebski
2007-11-30 1:26 ` Johan Herland
@ 2007-11-30 7:16 ` Alex Riesen
1 sibling, 0 replies; 33+ messages in thread
From: Alex Riesen @ 2007-11-30 7:16 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Robin Rosenberg
Jakub Narebski, Fri, Nov 30, 2007 01:18:27 +0100:
> >> <s id="mercurial">
> >> Excellent. Uses HTTP or ssh. Remote access also
> >> works safely without locks over read-only network
>
> By the way, can Git be used with repository on lockless network
> filesystem? (Although with distributed SCM it perhaps be better
> to just use many distributed repositories...). How does it work
> with repository available via SMBFS / CIFS or NFS?
Works fine. CIFS/SMBFS is slow as hell when hosted on windows, but I
figure it is not problem of Git.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Adding Git to Better SCM Initiative : Comparison
2007-11-29 20:07 ` Alex Riesen
2007-11-30 0:18 ` Jakub Narebski
@ 2007-11-30 18:34 ` Jan Hudec
1 sibling, 0 replies; 33+ messages in thread
From: Jan Hudec @ 2007-11-30 18:34 UTC (permalink / raw)
To: Alex Riesen; +Cc: Jakub Narebski, git, Robin Rosenberg
[-- Attachment #1: Type: text/plain, Size: 1710 bytes --]
On Thu, Nov 29, 2007 at 21:07:10 +0100, Alex Riesen wrote:
> Jakub Narebski, Thu, Nov 29, 2007 03:26:12 +0100:
> > + <s id="git">
> > + Medium. There's Git User's Manual, manpages, some
> > + technical documentation and some howtos. All
> > + documentation is also available online in HTML format;
> > + there is additional information (including beginnings
> > + of FAQ) on git wiki.
> > + Nevertheles one of complaints in surveys is insufficient
>
> "Nevertheless" (two "s").
I think it's not amount of documentation that's insufficient, but rather the
organization. The problem is not that the information is not there, but that
it's sometimes not easy to find.
> BTW, I wouldn't call the level of documentation "Medium" when compared
> to any commercial SCM. How can they earn more than "a little", when
> compared to any opensource program?
I don't know that many commercial SCM, but clearcase does have more than "a
little" documentation.
> [...]
>
> > @@ -1106,6 +1165,10 @@ TODO:
> > There exists some HTTP-functionality, but it is quite
> > limited.
> > </s>
> > + <s id="git">
> > + Good. Uses HTTPS (with WebDAV) or ssh for push,
> > + HTTP, FTP, ssh or custom protocol for fetch.
> > + </s>
>
> You forgot bundles (aka SneakerNet).
> Again, compared to everyone else it is "vastly superior" :)
In fact at least darcs and bzr can also do SneakerNet.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 33+ messages in thread
* Adding Git to Better SCM Initiative : Comparison
2007-11-28 22:39 Adding Git to Better SCM Initiative : Comparison Jakub Narebski
2007-11-29 1:48 ` Robin Rosenberg
2007-11-29 2:26 ` Jakub Narebski
@ 2007-12-03 19:57 ` Jakub Narebski
2 siblings, 0 replies; 33+ messages in thread
From: Jakub Narebski @ 2007-12-03 19:57 UTC (permalink / raw)
To: git
Below there is email I want to send to Shlomi Fish to have him include
GIT in "Better SCM Initiative : Comparison page".
Please check it and send comments and corrections. TIA.
-- >8 --
I have noticed that your SCM comparison at "Better SCM Initiative" website
http://better-scm.berlios.de/comparison/comparison.html
misses GIT, version control system which is used to manage Linux kernel.
GIT was created by Linus Torvalds in response to the change of BitKeeper
licensing, as a tool to manage Linux kernel sources. It is based on
three years of Linus experience with BitKeeper, and inspired by
Monotone architecture. It was designed for Linux kernel, and is used
by various projects, including X.Org, various Freedesktop projects, WINE,
OLPC (One Laptop Per Child), Samba.
<blurb src="http://git-scm.org">
Git is a popular version control system designed to handle very large projects
with speed and efficiency; it is used mainly for various open source projects,
most notably the Linux kernel.
Git falls in the category of distributed source code management tools, similar to
e.g. GNU Arch or Monotone (or BitKeeper in the proprietary world). Every Git
working directory is a full-fledged repository with full revision tracking
capabilities, not dependent on network access or a central server.
Git is an Open Source project covered by the GNU General Public License v2. It was
originally written by Linus Torvalds and is currently maintained by Junio C
Hamano.
</blurb>
Below there is patch to the sources for the site.
BTW. when asking about updating GIT info for comparison, please CC
git mailing list, git@vger.kernel.org
Index: src/comparison/scm-comparison.xml
===================================================================
--- src/comparison/scm-comparison.xml (revision 290)
+++ src/comparison/scm-comparison.xml (working copy)
@@ -38,6 +38,9 @@ <implementations>
<impl id="darcs">
<name>Darcs</name>
</impl>
+ <impl id="git">
+ <name>Git</name>
+ </impl>
<impl id="mercurial">
<name>Mercurial</name>
</impl>
@@ -106,6 +109,7 @@ <title>Atomic Commits</title>
<s id="svk">Commits are atomic.</s>
<s id="aegis">Commits are atomic.</s>
<s id="bitkeeper">Yes (but need to verify)</s>
+ <s id="git">Yes.</s>
<s id="mercurial">Yes.</s>
<s id="monotone">Yes.</s>
<s id="opencm">Yes. Commits are atomic.</s>
@@ -142,6 +146,13 @@ <title>Files and Directories Moves or Renames</title>
<s id="darcs">Yes. Renames are supported.</s>
<s id="bitkeeper">Yes. Renames are supported.</s>
<s id="aegis">Yes. Renames are supported.</s>
+ <s id="git">
+ Yes (or no depending on interpretation). Git detects
+ renames based on content regardless of whether the
+ committer indicated the fact.
+ You can follow history of file across renames using
+ 'git log -M --follow'.
+ </s>
<s id="mercurial">Yes. Renames are supported.</s>
<s id="monotone">Yes. Renames are supported.</s>
<s id="opencm">Yes. Renames are supported</s>
@@ -214,6 +225,13 @@ <title>File and Directories Copies</title>
Yes. Copies are supported.
</s>
<s id="aegis">No. Copies are not supported.</s>
+ <s id="git">
+ Yes (or no depending on interpretation). Git detects
+ copies (when requested) based on content regardless
+ of whether the committer indicated the fact.
+ You can follow history of file across copies using
+ 'git log -C -C --follow'.
+ </s>
<s id="mercurial">Yes. Copies are supported</s>
<s id="monotone">Yes. Copies are supported</s>
<s id="opencm">No. Copies are not supported.</s>
@@ -267,6 +285,7 @@ <title>Remote Repository Replication</title>
<s id="darcs">Yes.</s>
<s id="bitkeeper">Yes.</s>
<s id="aegis">Yes.</s>
+ <s id="git">Yes.</s>
<s id="mercurial">Yes.</s>
<s id="monotone">Yes.</s>
<s id="opencm">No.</s>
@@ -313,6 +332,7 @@ <title>Propagating Changes to Parent Repositories</title>
<s id="darcs">Yes.</s>
<s id="bitkeeper">Yes.</s>
<s id="aegis">Yes.</s>
+ <s id="git">Yes.</s>
<s id="mercurial">Yes.</s>
<s id="monotone">Yes.</s>
<s id="opencm">No.</s>
@@ -373,6 +393,10 @@ <title>Repository Permissions</title>
<s id="svk">
Same as subversion.
</s>
+ <s id="git">
+ Partial (?). It is possible to lock down repository
+ (access to branches and tags) using hooks.
+ </s>
<s id="mercurial">
Yes. It is possible to lock down repositories,
subdirectories, or files using hooks.
@@ -455,6 +479,13 @@ <title>Changesets' Support</title>
<s id="darcs">
Yes. Changesets are supported.
</s>
+ <s id="git">
+ Yes. Changesets are supported.<br />
+ Actually Git is snapshot based which means Git records
+ the full state in every commit. This means that any two
+ commits can be compared directly very quickly, although the
+ repository is typically browsed as a series of changesets.
+ </s>
<s id="mercurial">
Yes. Changesets are supported.
</s>
@@ -509,6 +540,11 @@ <title>Tracking Line-wise File History</title>
<s id="arch">Not in the command line client, but ViewARCH,
a web-interface for Arch, has it.</s>
<s id="darcs">Yes. (darcs annotate)</s>
+ <s id="git">
+ Yes. (git blame, git gui blame).
+ It can also detect the origin of copied and moved source
+ lines, and can ignore whitespace changes.
+ </s>
<s id="mercurial">Yes. (hg annotate)</s>
<s id="monotone">Yes, as of version 0.19.</s>
<s id="aegis">Yes. aeannotate</s>
@@ -570,6 +606,11 @@ <title>Ability to Work only on One Directory...</title>
whole.
</s>
<s id="aegis">No. All changes are made repository-wide.</s>
+ <s id="git">
+ No. All changes are made repository-wide. However
+ it is possible to commit only selected changes in the
+ working tree rather than everything. You can also
+ use submodules (subproject) support.</s>
<s id="mercurial">
It is possible to commit changes only in a subset of the
tree. There are plans for partial checkouts.
@@ -636,6 +677,10 @@ <title>Tracking Uncommited Changes</title>
Yes, using "darcs whatsnew".
</s>
<s id="aegis">Yes. Using aediff</s>
+ <s id="git">
+ Yes, of course. Using git diff.
+ Note that git uses staging area for commits (index).
+ </s>
<s id="mercurial">Yes. Using hg diff.</s>
<s id="monotone">Yes. In a similar fashion to CVS.</s>
<s id="opencm">Yes. Using cm diff</s>
@@ -681,6 +726,11 @@ <title>Per-File Commit Messages</title>
<s id="darcs">
No.
</s>
+ <s id="git">
+ No. The message applies to the commit as a whole.
+ But you can tag (with description) given contents
+ of a file (blob).
+ </s>
<s id="mercurial">
No.
</s>
@@ -782,6 +832,15 @@ <title>Documentation</title>
and the client contains a help tool that offers
an integrated help system.
</s>
+ <s id="git">
+ Good. There's Git User's Manual, manpages, some
+ technical documentation and some howtos. All
+ documentation is also available
+ <a href="http://www.kernel.org/pub/software/scm/git/docs">online</a>
+ in HTML format; there is additional information (including
+ beginnings of FAQ) on a
+ <a href="http://git-scm.org/gitwiki">git wiki</a>.
+ </s>
<s id="mercurial">
Very good. There's an overview and tutorial on the
web site, and integrated help for every command.
@@ -894,6 +953,16 @@ <title>Ease of Deployment</title>
to install the subversion perl bindings and a few modules
from CPAN.
</s>
+ <s id="git">
+ Very good. Install from RPM or deb on Linux; use
+ msysGit or Cygwin install on Windows. Git requires
+ zlib; also POSIX shell and utilities and Perl for some
+ commands.
+ Installing from sources is easy: Makefile has ready
+ configuration for many OS, you can also use autoconf
+ to generate Makefile configuration. Compiling docs
+ requires asciidoc toolchain, but you can use prebuild.
+ </s>
<s id="mercurial">
Excellent. Binary packages are available for all
popular platforms. Building from source requires
@@ -1006,6 +1075,13 @@ <title>Command Set</title>
but since the model is different most commands are
unique.
</s>
+ <s id="git">
+ Tries to follow CVS conventions, but deviates where there
+ is a different design (following BitKeeper for DVCS).
+ Large command set (~140) is divided into plumbing commands
+ (low lewel, to be used in scripts) and porcelain (high level).
+ It is easy to add new commands as scripts, or as git aliases.
+ </s>
<s id="mercurial">
Tries to follow CVS conventions, but deviates where there
is a different design.
@@ -1106,6 +1182,13 @@ <title>Networking Support</title>
There exists some HTTP-functionality, but it is quite
limited.
</s>
+ <s id="git">
+ Excellent. Uses HTTPS (with WebDAV) or ssh for push
+ (to publish changes to server) and HTTP, FTP, ssh or custom
+ "git" protocol for fetch (read from server). There is also
+ git-bundle for offline transport, and tools to exchange
+ (create and apply) patches via email.
+ </s>
<s id="mercurial">
Excellent. Uses HTTP or ssh. Remote access also
works safely without locks over read-only network
@@ -1203,6 +1286,11 @@ <title>Portability</title>
Very good. Supports many UNIXes, Mac OS X, and Windows,
and is written in a portable language.
</s>
+ <s id="git">
+ Good to very good. Portable across all POSIX systems.
+ There exists Win32 binary using MinGW (msysGit),
+ or you can use binary provided by Cygwin.
+ </s>
<s id="mercurial">
Excellent. Runs on all platforms supported by
Python. Repositories are portable across CPU
@@ -1300,6 +1388,10 @@ <title>Web Interface</title>
is included in the distribution.
</s>
<s id="aegis">Yes.</s>
+ <s id="git">
+ Yes, gitweb is included in git since version 1.4.0.
+ Other web interfaces exists: cgit, wit, git-php
+ </s>
<s id="mercurial">Yes. The web interface is a bundled component.</s>
<s id="monotone">No.</s>
<s id="opencm">No.</s>
@@ -1373,6 +1464,12 @@ <title>Availability of Graphical User-Interfaces.</title>
<s id="aegis">
There is tkaegis.
</s>
+ <s id="git">
+ There is history viewer 'gitk' and commit tool 'git-gui';
+ both in Tcl/Tk. There also exists a number of third-party
+ GUIs, including: qgit (Qt), GitView (GTK+), Giggle (GTK+),
+ tig (ncurses).
+ </s>
<s id="mercurial">
History viewing available with hgit extension;
check-in extension (hgct) makes committing easier.
@@ -1453,6 +1550,7 @@ <title>License</title>
GNU GPL (open-source)
</s>
<s id="svk">Perl License. (open source)</s>
+ <s id="git">GNU GPL v2 (open source)</s>
<s id="mercurial">GNU GPL (open source)</s>
<s id="monotone">GNU GPL (open source)</s>
<s id="opencm">
^ permalink raw reply [flat|nested] 33+ messages in thread
* Adding Git to Better SCM Initiative : Comparison
@ 2007-12-10 12:57 Jakub Narebski
2007-12-10 13:09 ` Eyvind Bernhardsen
` (3 more replies)
0 siblings, 4 replies; 33+ messages in thread
From: Jakub Narebski @ 2007-12-10 12:57 UTC (permalink / raw)
To: Shlomi Fish; +Cc: git
I have noticed that your SCM comparison at "Better SCM Initiative"
website
http://better-scm.berlios.de/comparison/comparison.html
misses one of the Git, version control system which is used to manage
Linux kernel, and one of the main open source (distributed) version
control systems (among Mercurial, Bazaar-NG, Monotone and Darcs).
Git used to be "stupid content tracker", something to build
user-friendly SCM interface on (e.g. Cogito) but it evolved into fully
fledged SCM since.
Git was created by Linus Torvalds in response to the change of BitKeeper
licensing, as a tool to manage Linux kernel sources. It is based on
three years of Linus experience with BitKeeper, and inspired by
Monotone architecture. It was designed for Linux kernel, and is used
by various projects, including X.Org, various Freedesktop projects,
WINE, OLPC (One Laptop Per Child), Samba.
<blurb src="http://git-scm.org">
Git is a popular version control system designed to handle very large
projects with speed and efficiency; it is used mainly for various open
source projects, most notably the Linux kernel.
Git falls in the category of distributed source code management tools,
similar to e.g. GNU Arch or Monotone (or BitKeeper in the proprietary
world). Every Git working directory is a full-fledged repository with
full revision tracking capabilities, not dependent on network access or
a central server.
Git is an Open Source project covered by the GNU General Public License v2.
It was originally written by Linus Torvalds and is currently maintained
by Junio C Hamano.
</blurb>
Below there is (slightly doctored) patch to the sources for the site.
BTW. when asking about updating GIT info for comparison, please CC
git mailing list, git@vger.kernel.org
Index: src/comparison/scm-comparison.xml
===================================================================
--- src/comparison/scm-comparison.xml (revision 290)
+++ src/comparison/scm-comparison.xml (working copy)
@@ -38,6 +38,9 @@ <implementations>
<impl id="darcs">
<name>Darcs</name>
</impl>
+ <impl id="git">
+ <name>Git</name>
+ </impl>
<impl id="mercurial">
<name>Mercurial</name>
</impl>
@@ -106,6 +109,7 @@ <title>Atomic Commits</title>
<s id="svk">Commits are atomic.</s>
<s id="aegis">Commits are atomic.</s>
<s id="bitkeeper">Yes (but need to verify)</s>
+ <s id="git">Yes.</s>
<s id="mercurial">Yes.</s>
<s id="monotone">Yes.</s>
<s id="opencm">Yes. Commits are atomic.</s>
@@ -142,6 +146,13 @@ <title>Files and Directories Moves or Renames</title>
<s id="darcs">Yes. Renames are supported.</s>
<s id="bitkeeper">Yes. Renames are supported.</s>
<s id="aegis">Yes. Renames are supported.</s>
+ <s id="git">
+ Yes (or no depending on interpretation). Git detects
+ renames based on content regardless of whether the
+ committer indicated the fact.
+ You can follow history of file across renames using
+ 'git log -M --follow'.
+ </s>
<s id="mercurial">Yes. Renames are supported.</s>
<s id="monotone">Yes. Renames are supported.</s>
<s id="opencm">Yes. Renames are supported</s>
@@ -214,6 +225,13 @@ <title>File and Directories Copies</title>
Yes. Copies are supported.
</s>
<s id="aegis">No. Copies are not supported.</s>
+ <s id="git">
+ Yes (or no depending on interpretation). Git detects
+ copies (when requested) based on content regardless
+ of whether the committer indicated the fact.
+ You can follow history of file across copies using
+ 'git log -C -C --follow'.
+ </s>
<s id="mercurial">Yes. Copies are supported</s>
<s id="monotone">Yes. Copies are supported</s>
<s id="opencm">No. Copies are not supported.</s>
@@ -267,6 +285,7 @@ <title>Remote Repository Replication</title>
<s id="darcs">Yes.</s>
<s id="bitkeeper">Yes.</s>
<s id="aegis">Yes.</s>
+ <s id="git">Yes.</s>
<s id="mercurial">Yes.</s>
<s id="monotone">Yes.</s>
<s id="opencm">No.</s>
@@ -313,6 +332,7 @@ <title>Propagating Changes to Parent Repositories</title>
<s id="darcs">Yes.</s>
<s id="bitkeeper">Yes.</s>
<s id="aegis">Yes.</s>
+ <s id="git">Yes.</s>
<s id="mercurial">Yes.</s>
<s id="monotone">Yes.</s>
<s id="opencm">No.</s>
@@ -373,6 +393,10 @@ <title>Repository Permissions</title>
<s id="svk">
Same as subversion.
</s>
+ <s id="git">
+ Partial (?). It is possible to lock down repository
+ (access to branches and tags) using hooks.
+ </s>
<s id="mercurial">
Yes. It is possible to lock down repositories,
subdirectories, or files using hooks.
@@ -455,6 +479,13 @@ <title>Changesets' Support</title>
<s id="darcs">
Yes. Changesets are supported.
</s>
+ <s id="git">
+ Yes. Changesets are supported.<br />
+ Actually Git is snapshot based which means Git records
+ the full state in every commit. This means that any two
+ commits can be compared directly very quickly, although the
+ repository is typically browsed as a series of changesets.
+ </s>
<s id="mercurial">
Yes. Changesets are supported.
</s>
@@ -509,6 +540,11 @@ <title>Tracking Line-wise File History</title>
<s id="arch">Not in the command line client, but ViewARCH,
a web-interface for Arch, has it.</s>
<s id="darcs">Yes. (darcs annotate)</s>
+ <s id="git">
+ Yes. (git blame, git gui blame).
+ It can also detect the origin of copied and moved source
+ lines, and can ignore whitespace changes.
+ </s>
<s id="mercurial">Yes. (hg annotate)</s>
<s id="monotone">Yes, as of version 0.19.</s>
<s id="aegis">Yes. aeannotate</s>
@@ -570,6 +606,11 @@ <title>Ability to Work only on One Directory...</title>
whole.
</s>
<s id="aegis">No. All changes are made repository-wide.</s>
+ <s id="git">
+ No. All changes are made repository-wide. However
+ it is possible to commit only selected changes in the
+ working tree rather than everything. You can also
+ use submodules (subproject) support.</s>
<s id="mercurial">
It is possible to commit changes only in a subset of the
tree. There are plans for partial checkouts.
@@ -636,6 +677,10 @@ <title>Tracking Uncommited Changes</title>
Yes, using "darcs whatsnew".
</s>
<s id="aegis">Yes. Using aediff</s>
+ <s id="git">
+ Yes, of course. Using git diff.
+ Note that git uses staging area for commits (index).
+ </s>
<s id="mercurial">Yes. Using hg diff.</s>
<s id="monotone">Yes. In a similar fashion to CVS.</s>
<s id="opencm">Yes. Using cm diff</s>
@@ -681,6 +726,11 @@ <title>Per-File Commit Messages</title>
<s id="darcs">
No.
</s>
+ <s id="git">
+ No. The message applies to the commit as a whole.
+ But you can tag (with description) given contents
+ of a file (blob).
+ </s>
<s id="mercurial">
No.
</s>
@@ -782,6 +832,15 @@ <title>Documentation</title>
and the client contains a help tool that offers
an integrated help system.
</s>
+ <s id="git">
+ Good. There's Git User's Manual, manpages, some
+ technical documentation and some howtos. All
+ documentation is also available
+ <a href="http://www.kernel.org/pub/software/scm/git/docs">online</a>
+ in HTML format; there is additional information (including
+ beginnings of FAQ) on a
+ <a href="http://git-scm.org/gitwiki">git wiki</a>.
+ </s>
<s id="mercurial">
Very good. There's an overview and tutorial on the
web site, and integrated help for every command.
@@ -894,6 +953,16 @@ <title>Ease of Deployment</title>
to install the subversion perl bindings and a few modules
from CPAN.
</s>
+ <s id="git">
+ Very good. Install from RPM or deb on Linux; use
+ msysGit or Cygwin install on Windows. Git requires
+ zlib; also POSIX shell and utilities and Perl for some
+ commands.
+ Installing from sources is easy: Makefile has ready
+ configuration for many OS, you can also use autoconf
+ to generate Makefile configuration. Compiling docs
+ requires asciidoc toolchain, but you can use prebuild.
+ </s>
<s id="mercurial">
Excellent. Binary packages are available for all
popular platforms. Building from source requires
@@ -1006,6 +1075,13 @@ <title>Command Set</title>
but since the model is different most commands are
unique.
</s>
+ <s id="git">
+ Tries to follow CVS conventions, but deviates where there
+ is a different design (following BitKeeper for DVCS).
+ Large command set (~140) is divided into plumbing commands
+ (low lewel, to be used in scripts) and porcelain (high level).
+ It is easy to add new commands as scripts, or as git aliases.
+ </s>
<s id="mercurial">
Tries to follow CVS conventions, but deviates where there
is a different design.
@@ -1106,6 +1182,13 @@ <title>Networking Support</title>
There exists some HTTP-functionality, but it is quite
limited.
</s>
+ <s id="git">
+ Excellent. Uses HTTPS (with WebDAV) or ssh for push
+ (to publish changes to server) and HTTP, FTP, ssh or custom
+ "git" protocol for fetch (read from server). There is also
+ git-bundle for offline transport, and tools to exchange
+ (create and apply) patches via email.
+ </s>
<s id="mercurial">
Excellent. Uses HTTP or ssh. Remote access also
works safely without locks over read-only network
@@ -1203,6 +1286,11 @@ <title>Portability</title>
Very good. Supports many UNIXes, Mac OS X, and Windows,
and is written in a portable language.
</s>
+ <s id="git">
+ Good to very good. Portable across all POSIX systems.
+ There exists Win32 binary using MinGW (msysGit),
+ or you can use binary provided by Cygwin.
+ </s>
<s id="mercurial">
Excellent. Runs on all platforms supported by
Python. Repositories are portable across CPU
@@ -1300,6 +1388,10 @@ <title>Web Interface</title>
is included in the distribution.
</s>
<s id="aegis">Yes.</s>
+ <s id="git">
+ Yes, gitweb is included in git since version 1.4.0.
+ Other web interfaces exists: cgit, wit, git-php
+ </s>
<s id="mercurial">Yes. The web interface is a bundled component.</s>
<s id="monotone">No.</s>
<s id="opencm">No.</s>
@@ -1373,6 +1464,12 @@ <title>Availability of Graphical User-Interfaces.</title>
<s id="aegis">
There is tkaegis.
</s>
+ <s id="git">
+ There is history viewer 'gitk' and commit tool 'git-gui';
+ both in Tcl/Tk. There also exists a number of third-party
+ GUIs, including: qgit (Qt), GitView (GTK+), Giggle (GTK+),
+ tig (ncurses).
+ </s>
<s id="mercurial">
History viewing available with hgit extension;
check-in extension (hgct) makes committing easier.
@@ -1453,6 +1550,7 @@ <title>License</title>
GNU GPL (open-source)
</s>
<s id="svk">Perl License. (open source)</s>
+ <s id="git">GNU GPL v2 (open source)</s>
<s id="mercurial">GNU GPL (open source)</s>
<s id="monotone">GNU GPL (open source)</s>
<s id="opencm">
^ permalink raw reply [flat|nested] 33+ messages in thread* Re: Adding Git to Better SCM Initiative : Comparison
2007-12-10 12:57 Jakub Narebski
@ 2007-12-10 13:09 ` Eyvind Bernhardsen
2007-12-10 13:20 ` Jakub Narebski
2007-12-10 14:33 ` David Kastrup
` (2 subsequent siblings)
3 siblings, 1 reply; 33+ messages in thread
From: Eyvind Bernhardsen @ 2007-12-10 13:09 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Shlomi Fish, git
On 10. des. 2007, at 13.57, Jakub Narebski wrote:
> I have noticed that your SCM comparison at "Better SCM Initiative"
> website
> http://better-scm.berlios.de/comparison/comparison.html
> misses one of the Git, version control system which is used to manage
"misses one of the Git"?
--
Eyvind
^ permalink raw reply [flat|nested] 33+ messages in thread* Re: Adding Git to Better SCM Initiative : Comparison
2007-12-10 12:57 Jakub Narebski
2007-12-10 13:09 ` Eyvind Bernhardsen
@ 2007-12-10 14:33 ` David Kastrup
2007-12-10 14:49 ` Florian Weimer
[not found] ` <200801071057.27710.shlomif@iglu.org.il>
3 siblings, 0 replies; 33+ messages in thread
From: David Kastrup @ 2007-12-10 14:33 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Shlomi Fish, git
Jakub Narebski <jnareb@gmail.com> writes:
> Git was created by Linus Torvalds in response to the change of BitKeeper
> licensing, as a tool to manage Linux kernel sources. It is based on
> three years of Linus experience with BitKeeper, and inspired by
of Linus' experience
> Monotone architecture. It was designed for Linux kernel, and is used
Monotone's architecture.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply [flat|nested] 33+ messages in thread* Re: Adding Git to Better SCM Initiative : Comparison
2007-12-10 12:57 Jakub Narebski
2007-12-10 13:09 ` Eyvind Bernhardsen
2007-12-10 14:33 ` David Kastrup
@ 2007-12-10 14:49 ` Florian Weimer
2007-12-10 15:23 ` Johannes Schindelin
` (3 more replies)
[not found] ` <200801071057.27710.shlomif@iglu.org.il>
3 siblings, 4 replies; 33+ messages in thread
From: Florian Weimer @ 2007-12-10 14:49 UTC (permalink / raw)
To: git
* Jakub Narebski:
> + <s id="git">
> + Yes (or no depending on interpretation). Git
This should be "No." (same for copies below).
> + <s id="git">
> + Partial (?). It is possible to lock down repository
> + (access to branches and tags) using hooks.
> + </s>
I doubt this works reliably. You still can access data once you've got
its SHA1 hash, for instance.
> + <s id="git">
> + Yes. Changesets are supported.<br />
> + Actually Git is snapshot based which means Git records
> + the full state in every commit. This means that any two
> + commits can be compared directly very quickly, although the
> + repository is typically browsed as a series of changesets.
> + </s>
I don't think this explanation is necessary. What does Subversion say?
> + <s id="git">
> + Yes. (git blame, git gui blame).
> + It can also detect the origin of copied and moved source
> + lines, and can ignore whitespace changes.
> + </s>
A simple "Yes." should suffice.
> @@ -636,6 +677,10 @@ <title>Tracking Uncommited Changes</title>
> Yes, using "darcs whatsnew".
> </s>
> <s id="aegis">Yes. Using aediff</s>
> + <s id="git">
> + Yes, of course. Using git diff.
> + Note that git uses staging area for commits (index).
> + </s>
Simply "Yes.". "git diff" is wrong, it's actually "git diff HEAD".
> @@ -681,6 +726,11 @@ <title>Per-File Commit Messages</title>
> <s id="darcs">
> No.
> </s>
> + <s id="git">
> + No. The message applies to the commit as a whole.
> + But you can tag (with description) given contents
> + of a file (blob).
> + </s>
Have we got any real tool support for this? This should be "No.".
> @@ -1006,6 +1075,13 @@ <title>Command Set</title>
> but since the model is different most commands are
> unique.
> </s>
> + <s id="git">
> + Tries to follow CVS conventions, but deviates where there
> + is a different design (following BitKeeper for DVCS).
I don't think this is true. Is there any command that closely matches
what CVS does?
> @@ -1203,6 +1286,11 @@ <title>Portability</title>
> Very good. Supports many UNIXes, Mac OS X, and Windows,
> and is written in a portable language.
> </s>
> + <s id="git">
> + Good to very good. Portable across all POSIX systems.
> + There exists Win32 binary using MinGW (msysGit),
> + or you can use binary provided by Cygwin.
> + </s>
Isn't Windows support still a bit lacking in terms of performance?
^ permalink raw reply [flat|nested] 33+ messages in thread* Re: Adding Git to Better SCM Initiative : Comparison
2007-12-10 14:49 ` Florian Weimer
@ 2007-12-10 15:23 ` Johannes Schindelin
2007-12-10 15:36 ` Florian Weimer
2007-12-10 15:47 ` Jakub Narebski
` (2 subsequent siblings)
3 siblings, 1 reply; 33+ messages in thread
From: Johannes Schindelin @ 2007-12-10 15:23 UTC (permalink / raw)
To: Florian Weimer; +Cc: git
Hi,
On Mon, 10 Dec 2007, Florian Weimer wrote:
> * Jakub Narebski:
>
> > + <s id="git">
> > + Yes (or no depending on interpretation). Git
>
> This should be "No." (same for copies below).
Nice. I have no idea what you are talking about, as you only quoted the
answer, but not the question. (Same for the other quoted text.)
Thanks,
Dscho
^ permalink raw reply [flat|nested] 33+ messages in thread* Re: Adding Git to Better SCM Initiative : Comparison
2007-12-10 15:23 ` Johannes Schindelin
@ 2007-12-10 15:36 ` Florian Weimer
0 siblings, 0 replies; 33+ messages in thread
From: Florian Weimer @ 2007-12-10 15:36 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
* Johannes Schindelin:
>> > + <s id="git">
>> > + Yes (or no depending on interpretation). Git
>>
>> This should be "No." (same for copies below).
>
> Nice. I have no idea what you are talking about, as you only quoted the
> answer, but not the question.
Oops. It's about the rename/copy detection stuff.
> (Same for the other quoted text.)
I tried to provide more context in those cases; the @@ lines should be
sufficient, I guess.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Adding Git to Better SCM Initiative : Comparison
2007-12-10 14:49 ` Florian Weimer
2007-12-10 15:23 ` Johannes Schindelin
@ 2007-12-10 15:47 ` Jakub Narebski
2007-12-10 16:28 ` Florian Weimer
2007-12-10 16:38 ` Linus Torvalds
2007-12-10 16:50 ` Chris Shoemaker
3 siblings, 1 reply; 33+ messages in thread
From: Jakub Narebski @ 2007-12-10 15:47 UTC (permalink / raw)
To: Florian Weimer; +Cc: git, Shlomi Fish
Florian Weimer <fw@deneb.enyo.de> writes:
> * Jakub Narebski:
> > @@ -214,6 +225,13 @@ <title>File and Directories Copies</title>
[...]
> > + <s id="git">
> > + Yes (or no depending on interpretation). Git
>
> This should be "No." (same for copies below).
I would agree to "N/A" or "Partial", but with 'git log --follow'
implemented at least for single file I wouldn't say that that git
doesn't support file and directories renames (copies). It does, in
it's own fashion, using rename (copy) detection instead of rename
(copy) tracking.
By the way, the explanation for "File and Directories Copies" section
itself is a bit imprecise; well at least it doesn't lead to easy
answer for git. I took it as question if we can examine _history_
of a file (or directory) across renames (copies). Other
interpretation would be if version control system in question
correctly handles renames and copies during merges... but it is in
TODO (Add intelligent merging of renamed paths.)
> > + <s id="git">
> > + Partial (?). It is possible to lock down repository
> > + (access to branches and tags) using hooks.
> > + </s>
>
> I doubt this works reliably. You still can access data once you've got
> its SHA1 hash, for instance.
So what? The data is not visible, so it is as if it didn't
exist. Besides if you are truly paranoid you can I think remove
downloaded pack.
By the way the default 'contrib/hooks/update-paranoid' implements ACL
restricting access to branches and tags, but I think that you can
write a hook which would refuse update if there are changes outside
specified subdirectory for example.
Note however that "repository permissions" are much more important for
centralized SCMs than for distributed SCMs, where you can form
"network of trust" (like Linus with his kernel's lieutenants and
subsystem maintainers).
> > + <s id="git">
> > + Yes. Changesets are supported.<br />
> > + Actually Git is snapshot based which means Git records
> > + the full state in every commit. This means that any two
> > + commits can be compared directly very quickly, although the
> > + repository is typically browsed as a series of changesets.
> > + </s>
>
> I don't think this explanation is necessary. What does Subversion say?
Subversion has the following currently:
Partial support. There are implicit changeset that are generated on
each commit.
Well, we could follow Mercurial, Monotone and Darcs and simply write
+ <s id="git">
+ Yes. Changesets are supported.
+ </s>
> > + <s id="git">
> > + Yes. (git blame, git gui blame).
> > + It can also detect the origin of copied and moved source
> > + lines, and can ignore whitespace changes.
> > + </s>
>
> A simple "Yes." should suffice.
Each SCM names the command for displaying line-wise file history,
if it of course exists.
While "can ignore whitespace changes" is not that important, detection
of contents movement and copying is important differentiation,
possible (or at least implemented) because Git uses rename detection
rather than rename tracking.
> > @@ -636,6 +677,10 @@ <title>Tracking Uncommited Changes</title>
> > Yes, using "darcs whatsnew".
> > </s>
> > <s id="aegis">Yes. Using aediff</s>
> > + <s id="git">
> > + Yes, of course. Using git diff.
> > + Note that git uses staging area for commits (index).
> > + </s>
>
> Simply "Yes.". "git diff" is wrong, it's actually "git diff HEAD".
Actually it depends on the definition of "uncommitted changes".
Besides "git diff HEAD" _is_ "using git diff".
But it's true that 'of course' there is not needed.
> > @@ -681,6 +726,11 @@ <title>Per-File Commit Messages</title>
> > <s id="darcs">
> > No.
> > </s>
> > + <s id="git">
> > + No. The message applies to the commit as a whole.
> > + But you can tag (with description) given contents
> > + of a file (blob).
> > + </s>
>
> Have we got any real tool support for this? This should be "No.".
True. But I'd rather leave it as "No. The message applies to the
commit as a whole." because that is important property.
> > @@ -1006,6 +1075,13 @@ <title>Command Set</title>
> > but since the model is different most commands are
> > unique.
> > </s>
> > + <s id="git">
> > + Tries to follow CVS conventions, but deviates where there
> > + is a different design (following BitKeeper for DVCS).
>
> I don't think this is true. Is there any command that closely matches
> what CVS does?
Yes: init, add, annotate (alias to blame), checkout, commit, diff,
status, log, version. At least in principle, if not in output format.
I don't think that Mercurial and Monotone follow CVS much better than
Git. (But that was one of answers I was having problems with.)
> > @@ -1203,6 +1286,11 @@ <title>Portability</title>
> > Very good. Supports many UNIXes, Mac OS X, and Windows,
> > and is written in a portable language.
> > </s>
> > + <s id="git">
> > + Good to very good. Portable across all POSIX systems.
> > + There exists Win32 binary using MinGW (msysGit),
> > + or you can use binary provided by Cygwin.
> > + </s>
>
> Isn't Windows support still a bit lacking in terms of performance?
That is more a problem with Windows, than Git ;-)
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Adding Git to Better SCM Initiative : Comparison
2007-12-10 15:47 ` Jakub Narebski
@ 2007-12-10 16:28 ` Florian Weimer
0 siblings, 0 replies; 33+ messages in thread
From: Florian Weimer @ 2007-12-10 16:28 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Shlomi Fish
* Jakub Narebski:
> Florian Weimer <fw@deneb.enyo.de> writes:
>
>> * Jakub Narebski:
>> > @@ -214,6 +225,13 @@ <title>File and Directories Copies</title>
> [...]
>> > + <s id="git">
>> > + Yes (or no depending on interpretation). Git
>>
>> This should be "No." (same for copies below).
>
> I would agree to "N/A" or "Partial", but with 'git log --follow'
> implemented at least for single file I wouldn't say that that git
> doesn't support file and directories renames (copies). It does, in
> it's own fashion, using rename (copy) detection instead of rename
> (copy) tracking.
It's undoubtly a difficult question. In my experience, developers tend
to not mark renames properly, so rename detection in log/diff/annotate
is still helpful even if renames are encoded explicitly. But this was a
learning process; I used to think that explicit rename support was
essential.
>> > + <s id="git">
>> > + Partial (?). It is possible to lock down repository
>> > + (access to branches and tags) using hooks.
>> > + </s>
>>
>> I doubt this works reliably. You still can access data once you've got
>> its SHA1 hash, for instance.
>
> So what? The data is not visible, so it is as if it didn't
> exist.
Uhm, I'd commit something that references some SHA-1, and voilà, I can
read the object with that SHA-1.
>> > + <s id="git">
>> > + Yes. Changesets are supported.<br />
>> > + Actually Git is snapshot based which means Git records
>> > + the full state in every commit. This means that any two
>> > + commits can be compared directly very quickly, although the
>> > + repository is typically browsed as a series of changesets.
>> > + </s>
>>
>> I don't think this explanation is necessary. What does Subversion say?
>
> Subversion has the following currently:
>
> Partial support. There are implicit changeset that are generated on
> each commit.
Hmm.
> Well, we could follow Mercurial, Monotone and Darcs and simply write
>
> + <s id="git">
> + Yes. Changesets are supported.
> + </s>
Makes sense, especially since there's "git bundle" nowadays.
>> I don't think this is true. Is there any command that closely matches
>> what CVS does?
>
> Yes: init, add, annotate (alias to blame), checkout, commit, diff,
> status, log, version. At least in principle, if not in output format.
I think we disagree on the meaning of "close" here. 8-/
In my experience, it's hard to see the parallels between GIT and CVS
because the semantics are so different. This is, to some extent,
unavoidable. But I'm not sure if knowing your way around CVS actually
helps learning GIT (the old sayings about BASIC come to my mind).
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Adding Git to Better SCM Initiative : Comparison
2007-12-10 14:49 ` Florian Weimer
2007-12-10 15:23 ` Johannes Schindelin
2007-12-10 15:47 ` Jakub Narebski
@ 2007-12-10 16:38 ` Linus Torvalds
2007-12-10 16:50 ` Chris Shoemaker
3 siblings, 0 replies; 33+ messages in thread
From: Linus Torvalds @ 2007-12-10 16:38 UTC (permalink / raw)
To: Florian Weimer; +Cc: git
On Mon, 10 Dec 2007, Florian Weimer wrote:
> * Jakub Narebski:
>
> > + <s id="git">
> > + Yes (or no depending on interpretation). Git
>
> This should be "No." (same for copies below).
No.
Git handles renames and copies better than most SCM's that _claim_ to
handle them. Saying we don't do them is just stupid. We do them *right*.
The fact that inferior systems do it differently is _their_ problem, and
not a cause for saying that git wouldn't do them.
Linus
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Adding Git to Better SCM Initiative : Comparison
2007-12-10 14:49 ` Florian Weimer
` (2 preceding siblings ...)
2007-12-10 16:38 ` Linus Torvalds
@ 2007-12-10 16:50 ` Chris Shoemaker
2007-12-10 17:21 ` Jakub Narebski
3 siblings, 1 reply; 33+ messages in thread
From: Chris Shoemaker @ 2007-12-10 16:50 UTC (permalink / raw)
To: Florian Weimer; +Cc: git
On Mon, Dec 10, 2007 at 03:49:39PM +0100, Florian Weimer wrote:
> * Jakub Narebski:
>
> > + <s id="git">
> > + Yes (or no depending on interpretation). Git
>
> This should be "No." (same for copies below).
ISTM that people are stuck using less than helpful criteria for
judging whether renames are supported. Namely, in effect, they ask:
"Does the user get to do extra work in order to get rename-detection?"
Let me humbly suggest an alternate, two-fold, very practical criteria
that I actually care about as a user:
1) If I edit file A, while another developer renames file A to B, and
I merge my work with his, do I have to clean things up myself, or does
everything Just Work?
2) If I'm browsing the history of some code in a renamed file, does
the history continue through the rename?
By these criteria, git certainly does support renames.
-chris
^ permalink raw reply [flat|nested] 33+ messages in thread* Re: Adding Git to Better SCM Initiative : Comparison
2007-12-10 16:50 ` Chris Shoemaker
@ 2007-12-10 17:21 ` Jakub Narebski
0 siblings, 0 replies; 33+ messages in thread
From: Jakub Narebski @ 2007-12-10 17:21 UTC (permalink / raw)
To: Chris Shoemaker; +Cc: Florian Weimer, Shlomi Fish, Linus Torvalds, git
Chris Shoemaker <c.shoemaker@cox.net> writes:
> On Mon, Dec 10, 2007 at 03:49:39PM +0100, Florian Weimer wrote:
> > * Jakub Narebski:
> >
> > > + <s id="git">
> > > + Yes (or no depending on interpretation). Git
> >
> > This should be "No." (same for copies below).
>
> ISTM that people are stuck using less than helpful criteria for
> judging whether renames are supported. Namely, in effect, they ask:
> "Does the user get to do extra work in order to get rename-detection?"
>
> Let me humbly suggest an alternate, two-fold, very practical criteria
> that I actually care about as a user:
>
> 1) If I edit file A, while another developer renames file A to B, and
> I merge my work with his, do I have to clean things up myself, or does
> everything Just Work?
The only thing Git doesn't implement _yet_ is when you have renamed
a directory, and another developer created a new file in the old
directory name. Currently Git creates new files in old directory.
Note however that moving files to other directory might need changes
in files: for example Java, or header files includes in C/C++. This
is not very common, though.
BTW. this issue is in TODO for "Better SCM : Comparison"
* Add intelligent merging of renamed paths.
> 2) If I'm browsing the history of some code in a renamed file, does
> the history continue through the rename?
And Git does support it in both "git blame" (or "git gui blame"),
and in "git log" thanks to --follow option.
Note however that --follow cannot be used (yet?) with directories or
pathspecs. Not that other SCMs support wildcard pathspec limiting...
> By these criteria, git certainly does support renames.
That's why I wrote "Yes", adding "or no" (as suggested by Robin
Rosenberg) because it does it dofferently than other SCMs.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply [flat|nested] 33+ messages in thread
[parent not found: <200801071057.27710.shlomif@iglu.org.il>]
* Re: Adding Git to Better SCM Initiative : Comparison
[not found] ` <200801071057.27710.shlomif@iglu.org.il>
@ 2008-01-13 0:44 ` Jakub Narebski
2008-01-14 0:14 ` Dmitry Potapov
0 siblings, 1 reply; 33+ messages in thread
From: Jakub Narebski @ 2008-01-13 0:44 UTC (permalink / raw)
To: Shlomi Fish
Cc: git, Eyvind Bernhardsen, David Kastrup, Florian Weimer,
Chris Shoemaker
On Mon, 7 Jan 2008, Shlomi Fish wrote:
>
> I'm CCing all the correspondents, because I'm banned from the vger.kernel.org
> mail. This has been an obstacle for me in several legitimate occassions and
> this one is the latest. I'm still CCing it, so the people in the mailing list
> will receive the replies.
>
> On Monday 10 December 2007, Jakub Narebski wrote:
> > I have noticed that your SCM comparison at "Better SCM Initiative"
> > website
> > http://better-scm.berlios.de/comparison/comparison.html
> > misses one of the Git, version control system which is used to manage
> > Linux kernel, and one of the main open source (distributed) version
> > control systems (among Mercurial, Bazaar-NG, Monotone and Darcs).
> >
>
> Indeed git is absent. That's because no one until you has volunteered to send
> a patch that adds it to the comparison. Another requirement is for someone to
> volunteer to become a "champion" for the version control system and maintain
> it into the future. So who is going to be the champion?
I can be git champion for "Better SCM Initiative" comparison... although
I'd rather somebody else was it.
[...]
> > Below there is (slightly doctored) patch to the sources for the site.
> >
>
> Despite the fact that I the comparison was recently patched to add Bazaar and
> fix some grammatical problems, the patch still applies cleanly. However, I
> saw that some people commented on it here. Can you send me a new patch
> integrating all this commentary?
I'll try to send revised patch soon. Integrating commentary is a bit
harder that it could be because some responses were sent _only_ to
git mailing list, so I'd have to browse through git mailing list
archives.
BTW. some of the questions / comments were caused by the fact that the
features listed in Better SCM Initiative: Comparison are a bit ambiguous.
What does for example "Atomic Commit" mean? Does it mean that if we
interrupt commit in the middle we would always get full commit or none,
and not some f**d-up intermediate state? Hos CVS can have atomic commits
then?
What does "Renames Support" mean? Does it mean that when browsing history
we [can] show file / directory renames? Does it mean that log of file or
directory history [can] follow renames? Does it mean that line-wise file
history [can] follow renames? Renames support in merges is as TODO, so
I don't think that this one matters in this question. Because the answer,
especially in the case of git which is a bit different in that it does
rename detection and not rename tracking (using inodes / file-ids),
depends on that...
--
Jakub Narebski
Poland
^ permalink raw reply [flat|nested] 33+ messages in thread* Re: Adding Git to Better SCM Initiative : Comparison
2008-01-13 0:44 ` Jakub Narebski
@ 2008-01-14 0:14 ` Dmitry Potapov
2008-01-14 0:31 ` Jakub Narebski
0 siblings, 1 reply; 33+ messages in thread
From: Dmitry Potapov @ 2008-01-14 0:14 UTC (permalink / raw)
To: Jakub Narebski
Cc: Shlomi Fish, git, Eyvind Bernhardsen, David Kastrup,
Florian Weimer, Chris Shoemaker
On Sun, Jan 13, 2008 at 01:44:10AM +0100, Jakub Narebski wrote:
>
> What does "Renames Support" mean?
Accordingly to the clarification provided there, it means retaining the
history of the file when its name changed. So I would write like this:
Yes. Git can automatically detects renames and show history together,
however being content oriented rather than file oriented, the notion of
"retaining the history of the file" can not exactly applied to it.
> Because the answer,
> especially in the case of git which is a bit different in that it does
> rename detection and not rename tracking (using inodes / file-ids),
> depends on that...
Git is different in that it tracks the content as the whole rather than
tracking a set of files. When you look at some source code, what you
really want to know who and why wrote *this*, and usually it does not
matter to you whether it was written in this file or another one. CVS
is really bad at that, because if you renamed a file, it would be very
difficult to go back to history and find that. Many file-ids based SCMs
have solved this problem, however, they do not do any better than CVS
in another very common case -- when your code is moved around as result
of refactoring, but Git addresses both problems, not just one!
So, it is not as much about explicit renaming vs automatic, but about
different design goals. After finishing reading this questionnaire,
it seems to me that a more proper title for it would be "Better CVS
Initiative", so it is not surprisingly that Git does not fit into it
well. It is like trying to put characteristics of your LCD into a
questionnaire for CRT monitors -- some does not make sense, other
misleading, and most important ones are not mentioned anyway...
Dmitry
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Adding Git to Better SCM Initiative : Comparison
2008-01-14 0:14 ` Dmitry Potapov
@ 2008-01-14 0:31 ` Jakub Narebski
2008-01-14 6:58 ` Dmitry Potapov
0 siblings, 1 reply; 33+ messages in thread
From: Jakub Narebski @ 2008-01-14 0:31 UTC (permalink / raw)
To: Dmitry Potapov, Shlomi Fish
Cc: git, Eyvind Bernhardsen, David Kastrup, Florian Weimer,
Chris Shoemaker
On Mon, 14 January 2008, Dmitry Potapov wrote:
> On Sun, Jan 13, 2008 at 01:44:10AM +0100, Jakub Narebski wrote:
> >
> > What does "Renames Support" mean?
By the way, the question was to the author of Better SCM Initiative
Comparison, Shlomi Fish.
> Accordingly to the clarification provided there, it means retaining the
> history of the file when its name changed. So I would write like this:
>
> Yes. Git can automatically detects renames and show history together,
> however being content oriented rather than file oriented, the notion of
> "retaining the history of the file" can not exactly applied to it.
"History of a file" can be defined as "<scm> log 'file'", and this is
well defined also for git. And 'rename support' for file means just
that this history of a file (of a current file contents) follows file
renames.
IIRC this des not work for directories... but on the other hand git,
tracking contents only as a goal, does not track directories.
> > Because the answer,
> > especially in the case of git which is a bit different in that it does
> > rename detection and not rename tracking (using inodes / file-ids),
> > depends on that...
>
> Git is different in that it tracks the content as the whole rather than
> tracking a set of files. When you look at some source code, what you
> really want to know who and why wrote *this*, and usually it does not
> matter to you whether it was written in this file or another one. CVS
> is really bad at that, because if you renamed a file, it would be very
> difficult to go back to history and find that. Many file-ids based SCMs
> have solved this problem, however, they do not do any better than CVS
> in another very common case -- when your code is moved around as result
> of refactoring, but Git addresses both problems, not just one!
AFAIK Mercurial (hg) is not file-id based, but does explicitely track
renames. There was even an idea presented on git mailing list to mark
renames in commit object in some "note" header.
> So, it is not as much about explicit renaming vs automatic, but about
> different design goals. After finishing reading this questionnaire,
> it seems to me that a more proper title for it would be "Better CVS
> Initiative", so it is not surprisingly that Git does not fit into it
> well. It is like trying to put characteristics of your LCD into a
> questionnaire for CRT monitors -- some does not make sense, other
> misleading, and most important ones are not mentioned anyway...
Please remember that AFAIK this table is _older_ than Git itself.
But it is a fact that some characteristics are much patterned after
CVS features and misfeatures.
It would be much better if for each feature there was some test
described which would allow to check if the feature is supported.
By the way, even before "git log --follow" you could have "this file
was renamed to that file" in the commit/revision patchset. This is
IMHO enough of rename support. Much more important is correct support
for renames in merges, which is in TODO for Better-SCM comparison...
--
Jakub Narebski
Poland
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Adding Git to Better SCM Initiative : Comparison
2008-01-14 0:31 ` Jakub Narebski
@ 2008-01-14 6:58 ` Dmitry Potapov
2008-01-14 12:14 ` Jakub Narebski
0 siblings, 1 reply; 33+ messages in thread
From: Dmitry Potapov @ 2008-01-14 6:58 UTC (permalink / raw)
To: Jakub Narebski
Cc: Shlomi Fish, git, Eyvind Bernhardsen, David Kastrup,
Florian Weimer, Chris Shoemaker
On Mon, Jan 14, 2008 at 01:31:19AM +0100, Jakub Narebski wrote:
> On Mon, 14 January 2008, Dmitry Potapov wrote:
>
> > Yes. Git can automatically detects renames and show history together,
> > however being content oriented rather than file oriented, the notion of
> > "retaining the history of the file" can not exactly applied to it.
>
> "History of a file" can be defined as "<scm> log 'file'", and this is
> well defined also for git.
You missed the key word here -- *retaining*. In fact, if you define the
history of a file just as something what "<scm> log" produce then what
is the problem with CVS here? Why do most people say that CVS does not
retain file history over rename? Certainly, you can type "cvs old-name"
and see history of one file, and if you type "cvs new-name" then history
of another... But somehow most people think about these two pieces as
being the history of *one* file... So, your definition is incorrect or,
at least, very different from what most people mean by that.
BTW, when you type "git log 'file'", it shows you not history of a file,
but history of changes that affect the specified paths...
> And 'rename support' for file means just
> that this history of a file (of a current file contents) follows file
> renames.
To equate a file with its contents is like to equate a variable with
its value. They are not exactly the same. If you renamed a file and
completely changed its contents, is it still the same file or not?
If you think about file as being inode then the answer is yes, but if
look at its content then the answer is no.
Git tracks contents, while many other SCMs tracks files regardless of
their contents. So, Git can show the history of file contents, but
not the history of a file...
>
> IIRC this des not work for directories...
Git works for directories, it is just that the --follow option cannot
applied to it, because this option means to follow the file contents,
which does not make much sense for directories.
> but on the other hand git,
> tracking contents only as a goal, does not track directories.
Exactly.
> >
> > Git is different in that it tracks the content as the whole rather than
> > tracking a set of files. When you look at some source code, what you
> > really want to know who and why wrote *this*, and usually it does not
> > matter to you whether it was written in this file or another one. CVS
> > is really bad at that, because if you renamed a file, it would be very
> > difficult to go back to history and find that. Many file-ids based SCMs
> > have solved this problem, however, they do not do any better than CVS
> > in another very common case -- when your code is moved around as result
> > of refactoring, but Git addresses both problems, not just one!
>
> AFAIK Mercurial (hg) is not file-id based, but does explicitely track
> renames. There was even an idea presented on git mailing list to mark
> renames in commit object in some "note" header.
I suspect the main reason why Mercurial support that is that a lot of
programmers whose mind was mangled by many years of CVS experience asked
for that feature. In practice, what you really want to track is contents.
And it is not difficult to add some "note" to the commit and teach Git to
follow it, but I don't see any practical value in that...
> > So, it is not as much about explicit renaming vs automatic, but about
> > different design goals. After finishing reading this questionnaire,
> > it seems to me that a more proper title for it would be "Better CVS
> > Initiative", so it is not surprisingly that Git does not fit into it
> > well. It is like trying to put characteristics of your LCD into a
> > questionnaire for CRT monitors -- some does not make sense, other
> > misleading, and most important ones are not mentioned anyway...
>
> Please remember that AFAIK this table is _older_ than Git itself.
> But it is a fact that some characteristics are much patterned after
> CVS features and misfeatures.
Well, if it is so old, that explains why it gave me such impression...
>
> It would be much better if for each feature there was some test
> described which would allow to check if the feature is supported.
Wanna test your LCD monitor with some old CRT tests? -:)
>
> By the way, even before "git log --follow" you could have "this file
> was renamed to that file" in the commit/revision patchset.
You could write that in CVS message too, but I don't think it can
be considered as retaining the history of the file...
Dmitry
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Adding Git to Better SCM Initiative : Comparison
2008-01-14 6:58 ` Dmitry Potapov
@ 2008-01-14 12:14 ` Jakub Narebski
0 siblings, 0 replies; 33+ messages in thread
From: Jakub Narebski @ 2008-01-14 12:14 UTC (permalink / raw)
To: Dmitry Potapov
Cc: Shlomi Fish, git, Eyvind Bernhardsen, David Kastrup,
Florian Weimer, Chris Shoemaker
Dnia poniedziałek 14. stycznia 2008 07:58, Dmitry Potapov napisał:
> On Mon, Jan 14, 2008 at 01:31:19AM +0100, Jakub Narebski wrote:
> > On Mon, 14 January 2008, Dmitry Potapov wrote:
> >
> > > Yes. Git can automatically detects renames and show history together,
> > > however being content oriented rather than file oriented, the notion of
> > > "retaining the history of the file" can not exactly applied to it.
> >
> > "History of a file" can be defined as "<scm> log 'file'", and this is
> > well defined also for git.
>
> You missed the key word here -- *retaining*. In fact, if you define the
> history of a file just as something what "<scm> log" produce then what
> is the problem with CVS here? Why do most people say that CVS does not
> retain file history over rename? Certainly, you can type "cvs old-name"
> and see history of one file, and if you type "cvs new-name" then history
> of another... But somehow most people think about these two pieces as
> being the history of *one* file... So, your definition is incorrect or,
> at least, very different from what most people mean by that.
I assume that 0th part of rename support is true, i.e. that we can
recover previous full-tree state of repository.
> BTW, when you type "git log 'file'", it shows you not history of a file,
> but history of changes that affect the specified paths...
The fact that in "git log <path>" the <path> part is path _limiter_
(and can be directory, or set of directories) rather than being limited
to simply single filename is what makes git different, both in good
("git log subsystem/path") and in bad (different from what other SCM
used to) way.
When you type "git log --follow='file'", it shows you history of
a _contents_ which currently is in 'file'; even if there were rename
in the history of 'file' somewhere in the past.
When you type "git log 'directory'", it shows you (simplified) history
of changes affesting specified directory (usually some subsystem).
IMHO "rename support" should be defined as
1.) showing renames when examining given revision (status, log, show;
whatever it is called).
2.) it should be able to follow history of a file when it looks like
this: add, change, rename, change.
> > And 'rename support' for file means just
> > that this history of a file (of a current file contents) follows file
> > renames.
[...]
> >
> > IIRC this des not work for directories...
>
> Git works for directories, it is just that the --follow option cannot
> applied to it, because this option means to follow the file contents,
> which does not make much sense for directories.
But it would be nice to have somehow "git log --follow=directory" work,
even if directory in which susystem resides was renamed. It is harder
work also because (I think) directories are more often split and joined
than file[s contents].
> > > Git is different in that it tracks the content as the whole rather than
> > > tracking a set of files. When you look at some source code, what you
> > > really want to know who and why wrote *this*, and usually it does not
> > > matter to you whether it was written in this file or another one. CVS
> > > is really bad at that, because if you renamed a file, it would be very
> > > difficult to go back to history and find that. Many file-ids based SCMs
> > > have solved this problem, however, they do not do any better than CVS
> > > in another very common case -- when your code is moved around as result
> > > of refactoring, but Git addresses both problems, not just one!
> >
> > AFAIK Mercurial (hg) is not file-id based, but does explicitely track
> > renames. There was even an idea presented on git mailing list to mark
> > renames in commit object in some "note" header.
>
> I suspect the main reason why Mercurial support that is that a lot of
> programmers whose mind was mangled by many years of CVS experience asked
> for that feature. In practice, what you really want to track is contents.
> And it is not difficult to add some "note" to the commit and teach Git to
> follow it, but I don't see any practical value in that...
Mercurial can be IMHO from architecture point of view be viewed a bit
as "CVS done right", much more than Subversion, with its path-hashed
changeset storage, manifest file, and changelog / changerev file.
And I guess that Mercurial supports this because of the most important
part of "renames support" (which is present only as TODO for Better-SCM
comparison), namely merging correct files in presence of renames.
> >
> > It would be much better if for each feature there was some test
> > described which would allow to check if the feature is supported.
>
> Wanna test your LCD monitor with some old CRT tests? -:)
If those tests were done correctly, not from technical side ("renames
support" and other similar thingies for SCMs, refresh rate for LCD/CRT),
but from user side (does command which shows history of a file follows
renames, eyestrain / image sharpness for monitors).... :-)
--
Jakub Narebski
Poland
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Adding Git to Better SCM Initiative : Comparison
@ 2008-01-13 15:05 linux
2008-01-13 15:16 ` Matthieu Moy
0 siblings, 1 reply; 33+ messages in thread
From: linux @ 2008-01-13 15:05 UTC (permalink / raw)
To: git, jnareb; +Cc: linux
> What does "Renames Support" mean? Does it mean that when browsing history
> we [can] show file / directory renames? Does it mean that log of file or
> directory history [can] follow renames? Does it mean that line-wise file
> history [can] follow renames? Renames support in merges is as TODO, so
> I don't think that this one matters in this question. Because the answer,
> especially in the case of git which is a bit different in that it does
> rename detection and not rename tracking (using inodes / file-ids),
> depends on that...
Let me make a bolder statement: a person asking for "rename support"
has been mentally damaged by using CVS too much.
CVS's fundamental problem is that it's a tree of versioned files. So a
file has to have a well-defined identity across versions, so CVS uses
the name, and that leads to problems if you rename the file.
And this is fundamentally broken. Both git and subversion do it right:
a repository is a versioned tree of files. Files don't have versions, but
rather versions have files. With this model, the problem Just Goes Away.
It doesn't exist any more. There's nothing to solve, nothing to do.
"Rename support" is a kludge to make a fundamentally broken model
less painful. Git doesn't have the problem, and so doesn't need,
doesn't have, and doesn't want the kludge. Indeed, as your questions
above show, it's hard to even define what it would be if it existed.
It's like asking if an electric light has a thoriated mantle, or inquiring
about the filament supply voltage of my mp3 player.
In all honesty, the correct answer is "no", git doesn't have that feature,
just like my laptop doesn't have a cooling water pressure sensor and
my solar-powered pocket calculator doesn't have a user-serviceable
mains fuse.
What's broken is the feature checklist. Someone has to go and re-think
the issue in a less CVS-centric way.
Just in case I was not clear enough above:
The need for a source file to have an identity
that persists across multiple revisions is an
artifact of CVS's implementation. Anyone asking
if a different version control system can preserve
that identity across renames needs to learn that
we now have ways of making light without fire.
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Adding Git to Better SCM Initiative : Comparison
2008-01-13 15:05 linux
@ 2008-01-13 15:16 ` Matthieu Moy
2008-01-13 16:25 ` Jakub Narebski
2008-01-13 18:42 ` linux
0 siblings, 2 replies; 33+ messages in thread
From: Matthieu Moy @ 2008-01-13 15:16 UTC (permalink / raw)
To: linux; +Cc: git, jnareb
linux@horizon.com writes:
> "Rename support" is a kludge to make a fundamentally broken model
> less painful.
It's not.
Git _has_ rename support. Look into the code, you'll find some code
whose purpose is to manage renames. And _no_, rename support is not
just a direct consequence of commits being atomic.
Atomic commit help, but if you do nothing else, moving a file and then
trying to merge will fail for example. So, in addition to atomic
commits, you have at least 3 options : explicit file ID (bzr),
recording renames (hg), or detecting renames after-the-fact (git).
--
Matthieu
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Adding Git to Better SCM Initiative : Comparison
2008-01-13 15:16 ` Matthieu Moy
@ 2008-01-13 16:25 ` Jakub Narebski
2008-01-13 18:42 ` linux
1 sibling, 0 replies; 33+ messages in thread
From: Jakub Narebski @ 2008-01-13 16:25 UTC (permalink / raw)
To: Matthieu Moy; +Cc: linux, git
On Sun, 13 January 2008, Matthieu Moy wrote:
> linux@horizon.com writes:
Can't you use a name or nick, by the way?
> > "Rename support" is a kludge to make a fundamentally broken model
> > less painful.
>
> It's not.
>
> Git _has_ rename support. Look into the code, you'll find some code
> whose purpose is to manage renames. And _no_, rename support is not
> just a direct consequence of commits being atomic.
>
> Atomic commit help, but if you do nothing else, moving a file and then
> trying to merge will fail for example. So, in addition to atomic
> commits, you have at least 3 options : explicit file ID (bzr),
> recording renames (hg), or detecting renames after-the-fact (git).
Rename detection / dealing with renames in SCMs is needed for:
0. Recovering previous state
1. Merging correct files
2. Forensic (log, blame) across renames / code movement
While the fact that Git is snapshot based and has whole-tree atomic
commits (Subversion does too) make it automatically obey 0., some
kind of rename support is needed for merges (Better SCM has it in TODO),
and for examining history, for example if the file was renamed in
one of the branches.
For example "git log --follow=gitweb/gitweb.perl" follows history of
specified file (IIRC this does not work for directory; but then Git
does not per se tracks directories), even if it was called gitweb.cgi
at the very beginning. "git blame -M" assign commit to a line denoting
when line was created, and not when it was moved (perhaps across file
boundaries) in the current place.
--
Jakub Narebski
Poland
^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Adding Git to Better SCM Initiative : Comparison
2008-01-13 15:16 ` Matthieu Moy
2008-01-13 16:25 ` Jakub Narebski
@ 2008-01-13 18:42 ` linux
2008-01-13 19:20 ` linux
1 sibling, 1 reply; 33+ messages in thread
From: linux @ 2008-01-13 18:42 UTC (permalink / raw)
To: Matthieu.Moy, linux; +Cc: jnareb, git
Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> linux@horizon.com writes:
>> "Rename support" is a kludge to make a fundamentally broken model
>> less painful.
>
> It's not.
>
> Git _has_ rename support. Look into the code, you'll find some code
> whose purpose is to manage renames. And _no_, rename support is not
> just a direct consequence of commits being atomic.
>
> Atomic commit help, but if you do nothing else, moving a file and then
> trying to merge will fail for example. So, in addition to atomic
> commits, you have at least 3 options : explicit file ID (bzr),
> recording renames (hg), or detecting renames after-the-fact (git).
Please forgive me for not mentioning that part. Yes, there are
interesting things to do with renames, and git is doing them, but I
skipped over them because they don't have much to do with the better-scm
definition of the feature:
"Does the system support moving a file or directory to a different
location while still retaining the history of the file?"
You can try to interpret it so it makes sense, but the question is
basically assuming that the history is attached to the file rather than
that the file is attached to the history.
With the latter model, the question is almost silly. Even with the very
primitive version of git that Linus used to make v2.6.12-rc2 with none
of that fancy code, you can rename a file and git retains the history.
Period. The qualification "of the file" doesn't even make sense.
As Linus has observed in the past, git does lots of fancy stuff to follow
the history of the code that's *in* the file, but the idea is that a file,
per se, doesn't have a history or even an identity.
You can ask about the history of a file *name*, or of a file's *contents*,
but if not that, what exactly is this "file" thing you want the history of?
Once you've answered that, you can then figure out if the answer to
the question based on whether the file has a history to retain in the
first place.
There are interesting questions about renames that you could ask, but
better-scm isn't asking questions like "can you resolve merges properly
after renaming a file on one branch?" Maybe I'm being uncharitable, but I
can't help but read the question as asking if the system has a workaround
for a well-known CVS problem. And one honest answer is "no, there's no
workaround; git doesn't suffer from the problem in the first place."
^ permalink raw reply [flat|nested] 33+ messages in thread
end of thread, other threads:[~2008-01-14 12:15 UTC | newest]
Thread overview: 33+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-11-28 22:39 Adding Git to Better SCM Initiative : Comparison Jakub Narebski
2007-11-29 1:48 ` Robin Rosenberg
2007-11-29 7:17 ` Jan Hudec
2007-11-29 2:26 ` Jakub Narebski
2007-11-29 20:07 ` Alex Riesen
2007-11-30 0:18 ` Jakub Narebski
2007-11-30 1:26 ` Johan Herland
2007-11-30 1:53 ` Jakub Narebski
2007-11-30 7:16 ` Alex Riesen
2007-11-30 18:34 ` Jan Hudec
2007-12-03 19:57 ` Jakub Narebski
-- strict thread matches above, loose matches on Subject: below --
2007-12-10 12:57 Jakub Narebski
2007-12-10 13:09 ` Eyvind Bernhardsen
2007-12-10 13:20 ` Jakub Narebski
2007-12-10 14:33 ` David Kastrup
2007-12-10 14:49 ` Florian Weimer
2007-12-10 15:23 ` Johannes Schindelin
2007-12-10 15:36 ` Florian Weimer
2007-12-10 15:47 ` Jakub Narebski
2007-12-10 16:28 ` Florian Weimer
2007-12-10 16:38 ` Linus Torvalds
2007-12-10 16:50 ` Chris Shoemaker
2007-12-10 17:21 ` Jakub Narebski
[not found] ` <200801071057.27710.shlomif@iglu.org.il>
2008-01-13 0:44 ` Jakub Narebski
2008-01-14 0:14 ` Dmitry Potapov
2008-01-14 0:31 ` Jakub Narebski
2008-01-14 6:58 ` Dmitry Potapov
2008-01-14 12:14 ` Jakub Narebski
2008-01-13 15:05 linux
2008-01-13 15:16 ` Matthieu Moy
2008-01-13 16:25 ` Jakub Narebski
2008-01-13 18:42 ` linux
2008-01-13 19:20 ` linux
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).