Re: Adding Git to Better SCM Initiative : Comparison

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:

quoted

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.
 
[...] 

quoted

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