From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9128 invoked by alias); 6 Oct 2009 14:07:24 -0000 Received: (qmail 9117 invoked by uid 22791); 6 Oct 2009 14:07:22 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx.meyering.net (HELO mx.meyering.net) (82.230.74.64) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 06 Oct 2009 14:07:15 +0000 Received: by rho.meyering.net (Acme Bit-Twister, from userid 1000) id B8AC78260; Tue, 6 Oct 2009 16:07:12 +0200 (CEST) From: Jim Meyering To: "H.J. Lu" Cc: Tom Tromey , GDB Subject: Re: gdb.git mirror is broken In-Reply-To: <6dc9ffc80910060608u60ccf9eal72ab51f216b7f75c@mail.gmail.com> (H. J. Lu's message of "Tue, 6 Oct 2009 06:08:22 -0700") References: <6dc9ffc80910051730p207a14f2m5ee6ff560ea60c33@mail.gmail.com> <87ws397z1b.fsf@meyering.net> <6dc9ffc80910060608u60ccf9eal72ab51f216b7f75c@mail.gmail.com> Date: Tue, 06 Oct 2009 14:07:00 -0000 Message-ID: <87ocok4nvz.fsf@meyering.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: 2009-10/txt/msg00096.txt.bz2 H.J. Lu wrote: > On Tue, Oct 6, 2009 at 12:38 AM, Jim Meyering wrote: >> H.J. Lu wrote: >> >>> Hi Jim, >>> >>> gdb.git mirror at >>> >>> http://sources.redhat.com/git/gdb.git >>> >>> is broken. The problems are >>> >>> 1: "cpu" directory is missing. >> >> Considering cpu/ has never been included in a gdb.git mirror >> (it's been explicitly excluded from the beginning), it may >> make sense to reconvert the repository from scratch, in order >> to include that directory and all of its history. >> >> However, that would have the disadvantage of changing all >> existing SHA1 commit values -- which might cause problems with >> the likes of archer.git. > > I didn't realize that cpu was excluded on purpose. I just > did a comparison between gdb tree checked out from CVS > and gdb tree checked out from git. I don't mind leaving it as is. > >>> 2. =C2=A0Top level files and gdb/gdbserver, bfd, sim, include directori= es >>> haven't been updated =C2=A0since 2009-09-16. >> >> I don't know what caused the process to stop mirroring >> those directories. =C2=A0It could be a bug in cvsps, git-cvsimport, >> my script, git-push, or even rsync. >> >> IMHO, the best would be to remove CVS from the loop. >> Leading up to that, I propose the following: >> >> =C2=A0I will re-convert all of gdb's CVS history to git (using parsecvs), >> =C2=A0not excluding the cpu/ directory this time. =C2=A0Then, I will add= checks >> =C2=A0to my mirroring script to notify me if git and CVS checkouts ever >> =C2=A0diverge. > > I am enclosing my script at the end of this email. It diffs > all ChangLogs between 2 gdb trees. > >> Note that the initial conversion is via parsecvs, >> yet incrementals are via my scripts, which rely on git-cvsimport >> (which in turn relies on cvsps). >> >> If anyone is interested in switching primary GDB development >> to git, once such a new repository is in place and deemed stable, >> I urge you to dump CVS. =C2=A0While the conversion tools are not always >> reliable, I can assure you that git itself has been amazingly reliable >> for years. >> > > It sounds a good idea. But don't we need to switch src tree to git, not > just gdb tree? I don't mind checking out the whole src tree. But we > need a way to build only gcc, gdb, binutils, .... even though there are > more packages. When gdb was the only project using this cvs-to-git mirroring, the status of these shared directories didn't really matter. Now that binutils also has a git mirror, perhaps we should think ahead to the day if/when everyone is using git and not CVS. Since some directories are shared between projects, one way would be to make each directory into its own git repository. Then, a separate gdb.git repository would include them via a git submodule. The way this would work is that gdb would record an SHA1 (that's about all a git submodule does) telling which bfd commit it is currently using. If bfd/ development is in a particularly unstable period, you may want to keep gdb's submodule pointing at some commit from before the disruptive changes started. Once bfd things stabilize, you would run a command telling git to record a newer bfd/ SHA1 in the gdb repository, and then you'd commit that meta-change. Here's an example of such a commit in coreutils, where I make it use the latest changes from gnulib: http://git.sv.gnu.org/cgit/coreutils.git/commit/?id=3D3c40fdfba612a0fad= 259de29adaeaf7554cfaf33 If I need to make a change in gnulib, I don't change coreutils/gnulib/, but rather make the change in a separate git clone'd gnulib tree, commit, and then push. Once I've pushed, I can then go back to my coreutils tree and tell it to sync from the latest upstream. I run this command: git syncsub which is just an alias for: git submodule foreach git pull origin master And then commit the result.