A Proposal to Move to Git

Tom Tromey <[email protected]>
Newsgroups gmane.comp.gnu.binutils,gmane.comp.gdb.devel
Message-ID <[email protected]>
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.