This is the mail archive of the
mailing list for the newlib project.
Re: A Proposal to Move to Git
- From: Andrew Pinski <pinskia at gmail dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: GDB Development <gdb at sourceware dot org>, Binutils Development <binutils at sourceware dot org>, newlib at sourceware dot org
- Date: Tue, 20 Aug 2013 14:15:57 -0700
- Subject: Re: A Proposal to Move to Git
- References: <8738q4gj7a dot fsf at fleche dot redhat dot com>
On Tue, Aug 20, 2013 at 2:12 PM, Tom Tromey <email@example.com> wrote:
> I'd like to move gdb and binutils from CVS to Git. I've done much of
> the preliminary work and I will do the remainder, including the
> inevitable follow-up bug-fixing.
Since newlib is part of the same repo, it would make sense to split
out newlib the same way you are splitting out gdb and binutils.
> I've read all the previous threads on the topic. I think I have
> internalized the big issues but it is possible that I am missing
> something. I'm sure you'll let me know.
> I think we should move specifically to git for two reasons. First, it
> is obviously better than CVS for the majority of work. Second, point
> #1 is borne out by observing that most active gdb developers are
> already using git. (I can't speak for binutils developers, though I
> do my rare binutils forays in git as well.)
> One principle I'm following in this proposal is to make the minimal
> change possible. That is, I want to focus on the conversion to git.
> Often times these discussions veer off into other process changes --
> removing ChangeLogs, stuff like that -- but for this change we ought
> to concern ourselves solely with the rollout of git, and leave other
> changes for a later date.
> So, if you have other changes you want to propose, I would appreciate
> it if you would hold them until the transition is complete.
> Note that there are even some absurd cases of this I am leaving
> in-tree; for example the requirements, obsolete with git, to put a
> date into a branch name.
> The basics of the plan are as outlined by Joseph Myers:
> For the purposes of this discussion I think you can focus on 6.b -- a
> shared gdb+binutils repository.
> The reason for a shared repository is simply that binutils and gdb
> share a substantial amount of code, mainly BFD, but other things as
> This gives the change minimal impact. It is not zero impact, but:
> 1. It is superior for all of us to build the whole tree, to avoid
> those (rare) occasions where BFD changes break other parts of the
> 2. You can already build just a subset of the tree;
> 3. This affects just the regular developers, not releases.
> I have been using http://sourceware.org/bugzilla/show_bug.cgi?id=14768
> to track the to-do items.
> My understanding of the task list is:
> * Update the gdbadmin scripts.
> I've done this though I have not tested them.
> * Update the BFD daily date-updating commit.
> Not done.
> * Port log_accum_bugzillafied to git and set up git commit email.
> I've done this and tested the post-receive parts.
> * Update DJ's script that auto-merges some changes from GCC.
> Note that I think it will have to continue to merge to the 'src' CVS
> repository, for the benefit of projects left behind.
> Not done.
> * Examine gdb and binutils documentation to see what needs to be
> updated. This means looking at the texinfo manuals, the web sites,
> and the gdb wiki.
> I have patches for this.
> Once the infrastructure bits are in place, there is the matter of the
> * Convert the tree. We can perhaps reuse parts of the existing
> conversion process for this. I will try a test conversion at least
> once. Since the old history is available
> (see http://sourceware.org/ml/binutils/2012-10/msg00407.html),
> we can try to merge it before conversion.
> There seem to be several approach we can take here. I am
> investigating the options, but I'm interested in your expert
> * Mark the various converted directories as read-only in CVS.
> This can be done via the commitinfo file.
> I'd like to do the final switch around mid-September. Not sooner,
> because I am going to be away for a little while near the end of
> August, and I want to be available to fix problems.