Any interest in using git for scm?

[Blair Zajac]

Darren Weber wrote:
> 
> In any case, regardless of keyword problems (if they persist in 
> git-svn), I'm glad to know that the svn repo is also in a git repo that 
> is tracking the svn.  The git repo should provide more integrity than 
> the svn repo and a reliable backup for the centralized svn repo.  (I 
> have no idea, but I assume the Mac OS Forge guys have a backup system 
> all wrapped up anyway, so not to worry about that.)  The point is that 
> the algorithms in git for sha1 checks are not available in any other 
> scm, AFAIK.

How does a git repo provide more integrity than svn?  There's nothing else in 
svn than we do to ensure that the repository and working copies are correctly 
protected.

Before making comparisions between git and svn, please do ask about the svn 
implementation.  I get the sense you've already decided and are interested about 
making a fair comparison.

> One advantage of the sha1 hash is that it provides a truly unique ID for 
> any commit, which probably surpasses the purpose of any $Id$ and other 
> keywords for tracking commits.  Using global config settings, like 
> user.name <http://user.name> and user.email, the commits are 
> automatically identified by the developer/commiter and they are useful 
> in 'git blame'.  Looking at the git log --graph or using gitk and other 
> git GUI tools gives a nice graph of the branch and commit history.  It 
> seems easy to identify where any changes came from.  No need for an Id 
> guidelines and associated developer conformity ;-)  (That may be one 
> reason that git doesn't support keywords ;-)).

The svn revision number is just as unique as the sha1 hash, in fact, guaranteed 
to be unique, unlike the extremely remote possibility that you get sha1 hash 
collision.

The $Id$ doesn't provide anything to track, it's just there so you can see 
without a svn log who last made the commit.

Blair