From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24265 invoked by alias); 14 Jan 2008 15:30:08 -0000 Received: (qmail 24200 invoked by uid 22791); 14 Jan 2008 15:30:06 -0000 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 14 Jan 2008 15:29:44 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 3C44A2A9A0E for ; Mon, 14 Jan 2008 10:29:42 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id sqvGptJbK-cW for ; Mon, 14 Jan 2008 10:29:42 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id E7C742A99FE for ; Mon, 14 Jan 2008 10:29:38 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id E94A9E7ACB; Mon, 14 Jan 2008 07:29:20 -0800 (PST) Date: Mon, 14 Jan 2008 15:30:00 -0000 From: Joel Brobecker To: gdb@sourceware.org Subject: using git to track the GDB CVS: A summary Message-ID: <20080114152920.GI9324@adacore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i 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: 2008-01/txt/msg00096.txt.bz2 Following a message I sent on this mailing list a few weeks ago regarding the use of git to track the GDB CVS tree, I received a few answers. My question was about importing the GDB CVS into a git repository. My hope was that the git-cvs bridge was sufficiently powerful and efficient that I would be able to have a "git" mirror of the public CVS. Given the size (in terms of number of changes) of the GDB project, and the extreme slowness of importing a CVS project through the network, I was hoping that it'd be possible to import the CVS HEAD and mirror the CVS tree from that point only. I haven't found a way to do that yet. I should ask on a git forum to confirm my findings (or lack thereof), but my searches on the web never talk of importing only partially a CVS tree. On the other hand, all the answers that I received used a hybrid CVS+git/hg approach. JimB reported that he has been using mercurial (hg) with great satisfaction. I will post his typical work-flow a little later, but the principles are the same, so I will talk about git only in the rest of my email. The idea is to checkout the GDB sources from CVS, and to import the result in git (including the CVS control files). You can then work on your changes using git. Once in a while, when you want to pull the latest changes in the FSF tree, you simply do a "cvs up" followed by "git commit". This is possible because the CVS files were kept during the initial import in git. Vladimir explained his work-flow as follow: > I have git repository which has a branch named 'mirror' and my > work branches. The 'mirror' branch was created by importing > CVS checkout of FSF tree -- and I did not remove the CVS directories. > > Say, I have branch always_inserted, which was originally created from > mirror, where I have several commits, converted them to emails and sent > to gdb-patches and one patch is approved. > > Then, I go this: > > 1. Switch back to mirror: > > git checkout mirror > > 2. Make sure it's up-to-date: > > cvs co gdb > > (Note that "co", on existing working copy, works just like "up", > but handles that 'modules' thing better). > > 3. Apply the approved patch > > git cherry-pick > > 4. Commit using CVS > > 5. Update git's branch > > git commit -a -m "Update" > > 6. Return back to work branch: > > git checkout always_inserted > > 7. Rebase: > > git rebase mirror > > The latter command is supposed to remove patches already present > in 'mirror'. > > So, in a certain sense the history of CVS HEAD is present, except that > individual CVS commits are not available. For mercurial, JimB described his typical work-flow as follow: > I'm using Mercurial (hg) for my GDB work, and I like it a whole lot. > I have one tree I call 'pub' that is both a CVS working copy and a hg > working copy. I never make changes there. Whenever I like, I run a > script that does (roughly): > > cd $pub > cvs -d :ext:jimb@sourceware.org:/cvs/src co gdb > cd $pub/src > hg addremove > hg commit -m 'from public CVS' > > Working copies for specific projects are then clones of pub, so I can > 'hg pull' to get public changes, and then 'hg merge' or 'hg update' as > appropriate. > > To commit a change, I 'hg push', then cd to pub and 'cvs commit'. > > Mercurial has a feature called 'queues' which helps maintain patch > series. To conclude this email, if I may make a personal judgement on these tools, I would say that I agree with Thiago who said that git is a great tool, but has an interface that I don't like (at least not yet). The issue might be that it's too different from svn, but I am thinking that the real problem is that it simply is too powerful and requires some commitment to learn it to a point where you it's no longer an obstacle in your work-flow. On the other hand, mercurial has a much simpler interface, and its simplicity has made it a real pleasure to use. Looking back now, using an import of a CVS checkout into a local SVN repository is, in terms of work-flow, a relatively practical solution. Since I'm still on the road for the next 10 days, I will stay with that solution for now. But the drawback is the extra complexity in the initial setup, and of course the larger amount of disk space occupied by the repository and the sandbox. -- Joel