Re: conversion to git

[Benoit SIGOURE]

On Sep 22, 2007, at 5:26 AM, Russ Allbery wrote:

> Andrej Prsa <address@hidden> writes:
>
> > Specifically, I did switch from CVS to Subversion about a year ago  
> > and
> > never regretted it. Now I would really like to learn what people  
> > have to
> > say about git.
>
> [SNIP: branching made easy and powerful]
> [SNIP: distributed: great]
> [SNIP: annoyed by sha1 sums compared to simple SVN rev]

I will add the following:
  - Extremely fast and optimized.  Generally, the first reaction  
that people have when they realize that you must clone a repo (and  
its entire history) if you want to checkout a git branch, they go  
like "wow, it must eat up a lot of disk space!".  As surprising at it  
might sound, Git needs generally less space to store the entire  
history of the project and a checked-out branch than having a SVN  
working copy (which has all the files stored twice + its meta-data in  
each .svn directory).  This is at least on what I observed on several  
of my 1500+ revision projects.
  - It's secure.  This alone should be enough to encourage people to  
switch to Git.  If you care about your data, you can't use any other  
SCM than Git.  With the single 40-byte sha1 of your HEAD, you can  
cryptographically guarantee the entire history that lead to this  
HEAD.  It's impossible to corrupt the repository without noticing  
it.  You can also sign commits and tags with your GPG key.
  - Merging is done right and easy, I think this is a consideration  
of utmost importance for developers.  SVN is broken in many respects,  
mainly because it doesn't know what a merge is.  In SVN a merge is  
simple a big patch.  You loose the entire history of this patch and  
don't know when/what has been merged.  This is plain wrong.
  - Git is extremely feature rich, it has lots of nifty tools that  
make developing easier and more efficient such as:
     * git-stash (>= git 1.5.3) http://www.kernel.org/pub/software/ 
scm/git/docs/git-stash.html
     * git-rerere http://www.kernel.org/pub/software/scm/git/docs/ 
git-rerere.html
     * git-bisect http://www.kernel.org/pub/software/scm/git/docs/ 
git-bisect.html
     * git-format-patch + git-send-email + git-am (apply mbox) make  
it very easy to properly exchange patches by e-mail (will retaining  
authorship and handling binary diff) -- ah yes, did I say that Git  
makes the difference between the committer and the author which is  
very suitable to projects with some maintainers and many contributors  
(such as this ML).
     * git-grep which makes it easy to grep all the files in the WC
     * Git can detect file renames and copies.
     * Git has a very powerful blaming tool (you can track the way a  
line or a function evolved through the repo, even if it was moved  
from one file to another in several commits)
     * You can pull/push via ssh or http/https+DAV (or simply pull  
via standard http/https) among other protocols.
     * Git has several merging tools and strategies that are quite  
powerful.
     * Git has several GUIs to make it easier to wander through the  
repository history (especially when its history is non-linear).
     * Builtin colored diff, status, diffstat (cherry on the cake)
  - Finally, Git has a rather good integration with SVN and decent  
integration with CVS.  Actually, I no longer use SVN for my SVN-based  
projects, Git turns out to be a much better SVN client than SVN itself.

As it was already pointed out, the Git community is increasing daily  
and more and more developers are joining and contributing to it's  
moving at a rather fast pace.  It's even hard to follow all the  
topics on their mailing list due to the large number of people  
sending patches and contributing to the discussions.

Generally speaking, contributing to Git-based project is very easy.   
A simple public-read-only access is needed, there is no need to have  
political arguments about who should be allowed to commit or not,  
anyone can commit in their repo and easily send their patch to the  
ML.  If they're good, they will be applied by some maintainer,  
otherwise they can easily be re-worked by its original author or  
simply forgot about and kept private in their repository.

From a maintainer point of view, Git is life changing because it  
helps in many tasks (testing topic branches, merging, publishing  
changes, applying / removing / editing patches, etc.) while being way  
faster than any other SCM (although bzr isn't far behind).

Now the downsides of Git:
  - Git is obviously more complicated than SVN (which was itself  
more complicated than CVS which was more complicated than RCS etc.   
this is normal).  So it takes some time to properly understand  
everything Git, but it's worth doing it because as a developer,  
having a SCM that helps you be more efficient is extremely valuable.
  - Git did not support something similar to svn:externals until  
very recently when Git-submodules have been added to the stable  
branch and released in 1.5.3.  So externals (aka Git-submodules)  
might be less well-documented.
  - Git does not support partial checkouts (which is a huge problem  
for extremely large repository because even though Git is very good  
at deltifying the entire repo, it can't magically turn 3 gigs of file  
in something small enough so you don't notice it on your hard  
drive).  For most projects consisting of source code however, this  
isn't a problem (see the KDE people who import 200 000+ revisions in  
Git).


Cheers,

--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory

PGP.sig
Description: This is a digitally signed message part