Re: A Proposal to Move to Git

[Andrew Pinski <pinskia at gmail dot com>]

On Tue, Aug 20, 2013 at 2:12 PM, Tom Tromey <tromey@redhat.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.

Thanks,
Andrew Pinski

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