Re: GIT and CVS

[André Pönitz <andre dot poenitz at nokia dot com>]

On Thursday 13 October 2011 21:37:22 ext Phil Muldoon wrote:
> 
> 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.

Not sure whether a mere gdb _user's_ input is asked for here, but as I
try to stay somewhat in touch with the code I am affected by the SCM 
system gdb uses, too. Only a little, but enough to care. 

So...

I personally don't _like_ git.

It just (subjectively...) happens to be best-of-breed right now, so it is 
what I use if I have a choice. For non-git based projects I often enough
create a local git 'mirror' for browsing, history walking etc. With gdb I find
myself almost exclusively using a clone of git://sourceware.org/git/gdb.git.

> 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?

After skipping the intermediate SVN step (which a lot of other projects had
and which probably would have been a decent solution for gdb for the period
2003-2010 or so, too) moving to git _now_ seems to be an excellent idea.

I have also the impression that most of the recent gdb improvements were
done by people using git and "ported" to CVS afterwards. Making the lifes
of active contributors easier by removing this extra step should benefit the 
project as a whole.

I've seen this suggestion has sparked quite some interest on the mailing
list in the meantime. I'd like to comment on a few comments.

* All ChangeLog related discussion is a red herring. One _could_ have a plain
text file called "ChangeLog" in a git repo without complications.

* "Git sucks on MS-Windows". Git is usable on Windows to a degree that projects
much bigger than gdb switched to it, after careful consideration of a lot of
alternatives, including commercial offerings. My main work currently is on a
smaller cross platform project about 3/4 the "total size" of gdb (including
bfd, libiberty,  etc) and this is certainly in a very usable state on Windows.

* The timing discussion revolves around use cases where git is slower, in
the single-digit or even fraction-of-a second range. The discussion, however, 
does not include any use cases reflecting workflows _enabled_ by that 
"slowness" that are not even remotely feasible in the CVS world. "git bisect"
comes to mind. Use it _once_ and you have set off a life time's worth of 
"wasting" half seconds on annotation. Not to mention the branching, 
merging and rebasing business. 


May I suggests a meritocratic approach to solve the problem, and simply let
the people who currently work on the code base choose the tools they want?

  git log @{"1 year ago"}..HEAD | grep ^Author: | sort | uniq -c | sort -n | tail -20

runs e.g. in "real 0m0.079, user 0m0.076s, sys 0m0.008" here, so at least 
in theory this could be a fairly quick decision. 

I understand this is unfair as it does not reflect the effort patch reviewers
have put into the project. Maybe mailing list activity can be incorporated in
the numbers. But I'd call it a starting point.

Andre'