GIT and CVS

[Phil Muldoon <pmuldoon at redhat dot com>]

At the risk of atomizing the poor horse, I want to refresh ideas and
thoughts on this.  

First, I'll point out I am in favor of GIT.  Not because GIT has won me
over heart-and-soul, but purely because I can work on GDB GIT offline.
This is not an inconsiderable benefit.  I can create local check-ins,
create branches, merge, cherry-pick all in the leisure of my own office,
or garden, or airport ... without internet access.

So that is my bias laid out.

So why are we still on CVS?  I'm not a release manager, so I do not have
to do the difficult work of cutting branches, and all of the difficult
work in making releases.  But what are the objections to GIT?
Personally, I'll give a strong bias to Joel's opinions because, frankly,
he has to deal with this issue far more than any other. 

GIT is, I think, available everywhere, has a CVS interface, and is
far, far quicker than CVS.  Maybe with the stronger identity and
information that comes with GIT logs we can finally retire
ChangeLogs.

CVS has served very well over the years.  I, and many others, cut our
teeth on it.  It's been a good system.  But beyond stability I
don't see it keeping up with functionality of other repository systems.
I find myself working on GIT 98% of the time, and the other 2% dealing
with CVS on the final check-in.  Surely I can't be the only hacker that
does this?  If the vast majority are in this work-flow, perhaps we
should think about the pros and the cons again.  I have no ideas about
the work-flows of my GDB hackers, and if, you know, we are all doing this
then we should recognize the elephant in the room.  If not, then I will
go happily into the (CVS) night, content on the validity of its use and
utility.

So, what do you think?

Cheers,
 
Phil