This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: GIT and CVS
Andrà PÃnitz <andre.poenitz@nokia.com> writes:
> 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.
It's asked for and welcomed.
> So...
>
> I personally don't _like_ git.
Right, I don't think it will any personality contests. But without
doubt it is powerful tool.
> 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.
I do too.
> 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.
Right, and what I asked with this email was to get a picture of the
contributors and what their workflow was. Is anyone using CVS on a
daily basis for active development. We cannot go to the server and get
usage stats as each commit has to use CVS.
> * All ChangeLog related discussion is a red herring. One _could_ have a plain
> text file called "ChangeLog" in a git repo without complications.
I think mixing these two topics was wrong on my part
.
> * "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.
That's interesting, is there an active community around GIT there?
> * 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.
The one workflow, to me, is cvs diffs. Maybe it is because I am in the
UK but CVS diffs are just painfully slow. And commits. Sometimes
taking 10+ minutes to complete.
Cheers,
Phil