Re: [Census] So who uses git?

From: Keith Packard <keithp@keithp.com>
Date: Jan 29, 2006, 10:09 UTC
Message-ID: <1138529385.9919.185.camel@evo.keithp.com>
In-Reply-To: <7vzmlgt5zt.fsf@assigned-by-dhcp.cox.net>

On Sat, 2006-01-28 at 13:08 -0800, Junio C Hamano wrote:

Show 10 quoted lines

> Keith Packard <keithp@keithp.com> writes:
> 
> > Once we're happy with the import, I'm pretty sure we'll just switch
> > cairo over to git and dump the CVS bits. X.org is a harder case, for
> > that I suspect we'll migrate individual modules over one at a time,
> > perhaps starting with the core X server pieces so that I can get my work
> > done, have it published in the main repository and not have it also
> > break everyone else's X server.
> 
> Wow.......  You are switching Cairo and X.org from CVS to git?

We're not switching 'X.org', we're switching the X server core. X.org is now broken into many separate projects, and each one will get to choose SCM on their own. I expect to migrate the ones I maintain and use to git, but migration of the dead code is unlikely to ever happen (and there's lots of dead code)

Show 14 quoted lines

> It could be that anything is better than CVS these days, but I
> have to admit that my jaw dropped after reading this, primarily
> because I've have never touched anything as big as X.
> 
> Awestruck, dumbstruck,... Xstruck.  Yeah, I know I should have
> more faith in git.  Earlier I heard Wine folks are running git
> in parallel with CVS as their dual primary SCM now, and of
> course git is the primary SCM for the Linux kernel project.
> 
> For things like the source code management, it takes a new
> software to be at least 10 times as good as the one that has
> been used, because switching _is_ a pain no matter how well tool
> helps the transition.  You have to transition not just the
> repository, but people who interact with it.

Fortunately, there are very few people involved with any specific piece
of the X.org distribution; there's really only one or two people
actively developing the X.org core server, so that part of the migration
will be easy. Our users will be stuck, but there aren't many of them
either, and git makes just sucking the current bits pretty easy.

Show 5 quoted lines

> When the Linux kernel switched, it was not that hard to be
> infinitely better than the previous one.  Because the previous
> one was no longer available to the kernel community; git did not
> have to be 10 times better on technical merits alone when the
> transition happened.

git really does look 10x better than CVS at this point; mostly social issues are now blocking X development as weaker developers are refused access to source code management to protect the project from damage. git eliminates that barrier, and should let many new developers experiment and share their results without affecting my work

Show 9 quoted lines

> Can I hear experiences from other big projects that tried to use
> git [*1*]?  I suspect there are many that have tried, and I
> would not be surprised at all if git did not work out well for
> them.  For projects that already run on a (free) SCM, I would be
> very surprised if the developers find the current git 10 times
> better than the SCM they have been using (probably with an
> exception of CVS), unless they have very specific need, such as
> parallel development of distributed nature like the Linux
> kernel.

Everyone *wants* parallel distributed development, CVS prevents it. And, remember that this is *not* a huge project, the core X server is only 2M lines of source code. We separate out all of the drivers, libraries and applications. Doing the migration in pieces allows us to incrementally affect developers, and repair issues without suspending all development.

I don't know of other huge projects moving to git; it's not all that
interesting as we know the tool is stable and will scale to support our
project already. Also, hg and bzr are not ready for production use in my
opinion; hg as it appears likely a flag day will be required before 1.0,
and bzr because they didn't focus on repository format, and have
suggested that they will switch to a hash-addressed scheme at some point
in the future...

-- 
keith.packard@intel.com