This is the mail archive of the
mailing list for the binutils project.
A Proposal to Move to Git
- From: Tom Tromey <tromey at redhat dot com>
- To: GDB Development <gdb at sourceware dot org>
- Cc: Binutils Development <binutils at sourceware dot org>
- Date: Tue, 20 Aug 2013 15:12:41 -0600
- Subject: A Proposal to Move to Git
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.
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.
* 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.
* 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
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.