A Proposal to Move to Git

[Tom Tromey <tromey@redhat.com>]

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:

    http://gcc.gnu.org/ml/gcc/2011-03/msg00486.html

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
well.

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
   build;

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
conversion:

* 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
  advice.

* 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.

Tom