moving to git (was: moving to subversion)

Stefan Sperling stsp at
Mon Sep 4 10:43:01 CEST 2006

On Sun, Sep 03, 2006 at 08:05:24PM +0200, Stefan Sperling wrote:
> On Sun, Sep 03, 2006 at 06:54:34PM +0200, Vapula wrote:
> > PS : how about moving to SVN, it should be lighter on the server, shouldn't
> > it ?
> I am considering moving to git, but not too soon,

I've switched to the fvwm window manager recently (I must say
I'm very impressed), and used the opportunity of having to keep
modifying my window manager configuration file to investigate git
a little further (again, I must say I'm very impressed).

To be honest, out of sheer lazyness I started out using cvs for version
control of my fvwm configuration. This turned out to be quite fortunate
however, since I could test cvs->git migration on a small scale (one file).

The following has to be said about migrating to git:

On the plus side: It will rock!
Git suits our development model very well. Branching is encouraged,
and much more easy to use and natural than with cvs. We can move things
around seemlessly without spoiling the history. Git seems to allow almost
anything in the repository, even symlinks! And there is no binary/text
data problem.

On the downside:
Committers will have to learn how to use git properly.
This takes a bit of time. The documentation is very good,
but uses very informal style with a couple of jokes thrown
in here and there. While this keeps things from getting
too boring, you have to get used to the style of the
documentation a bit before you know what is going on.

Of course, we cannot expect anyone to learn git from scratch in
a single day. However, we should all put in some effort to learn
about git at the same time so that migration goes smoothly.
The git wiki is a good starting point:
After having read the "tutorial", the "git for CVS users" guide and
"the Everyday Git handbook" (very small for a "handbook"), anyone
should be able to get going with git and to use the man pages for
further reference. During migrarion, I will also adapt our cvs documentation
in the wiki, so if you are unsure of how to do anything, you can look in there,

About the migrating process:

Even though git encourages distributed development, I would
like to keep a central master repository on a fast server,
simply because our tree is very large and I don't think
developers would like to pull changes from each other over slow
uplinks. The central repository at in-berlin is also backed up regularly.

Migrating from cvs to git turns out to be relatively seamless on
the repository maintainer's side. Git supports cvs conversion,
and the best thing is that the conversion is incremental (create
gitified copy of repository once, then get new changes every now and then).
That means I can set up git-based infrastructure for the project
while we still use cvs to commit new stuff.

I've already figured out how to get git to send commit email.

There's also a git-to-cvs program that simulates anonymous cvs access
on a git repository. This means that users can (optionally) keep using
anoncvs even after migration. 

So basically, I can slowly start setting up git infrastructure, work on
updating the documentation accordingly (esp. documentation for developers
and comitters), set up a public repository mirror and do some testing
whenever I have some spare time. At some point it will hopefully be usable,
and we can declare the cvs repository obsolete. At that point, committers
should know how to use git.

Any objections?
stefan                                 PGP Key: 0xF59D25F0

More information about the dslinux-devel mailing list