From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5009 invoked by alias); 14 Oct 2011 12:36:20 -0000 Received: (qmail 4838 invoked by uid 22791); 14 Oct 2011 12:36:18 -0000 X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp.nokia.com (HELO mgw-da01.nokia.com) (147.243.128.24) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 14 Oct 2011 12:36:03 +0000 Received: from gar.localnet (berwst16747.europe.nokia.com [172.25.167.47]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p9ECa14c031515 for ; Fri, 14 Oct 2011 15:36:01 +0300 From: =?iso-8859-1?q?Andr=E9_P=F6nitz?= To: gdb@sourceware.org Subject: Re: GIT and CVS Date: Fri, 14 Oct 2011 12:36:00 -0000 User-Agent: KMail/1.13.5 (Linux/2.6.35-30-generic; KDE/4.5.5; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201110141435.59962.andre.poenitz@nokia.com> X-Nokia-AV: Clean X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2011-10/txt/msg00116.txt.bz2 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'