Re: [Contrib PATCH] Add scripts to convert GCC repo from SVN to Git

[Joseph Myers <joseph at codesourcery dot com>]

On Fri, 23 Aug 2019, Maxim Kuvyrkov wrote:

> I propose that we switch to gcc-pretty.git repository, because it has 
> accurate Committer and Author fields.  Developer names and email 
> addresses are extracted from source history, and accurately track people 
> changing companies, email addresses, and names.  IMO, it is more 
> important for people to get credit for open-source contributions on 
> github, ohloh, etc., than the inconvenience of rebasing local git 
> branches.  It's also an important marketing tool for open-source 
> companies to show stats of their corporate email addresses appearing in 
> git commit logs.

I concur that accurately crediting contributors is important and means we 
should not start from the existing mirror (though we should keep its 
branches available, so references to them and to their commit hashes 
continue to work - either keeping the existing repository available under 
a different name, or renaming the branches to put them in the new 
repository - which should not enlarge the repository much because blob and 
tree objects will generally be shared between the two versions of the 
history).

I note that the Go conversion of reposurgeon is now just five test 
failures away from passing the whole reposurgeon testsuite (at which point 
it should be ready for an attempt on the GCC conversion).  Given the good 
progress being made there at present, I thus suggest we plan to compare 
this conversion with one from reposurgeon (paying special attention to the 
messiest parts of the repository, such as artifacts from cvs2svn 
attempting to locate branchpoints), unless those last five goreposurgeon 
test failures prove unexpectedly time-consuming to get resolved.

There are of course plenty of things to do relating to a git conversion 
that do not depend on the particular choice of a converted repository - 
such as writing git hooks and git versions of the maintainer-scripts 
scripts that currently work with SVN, or working out a specific choice of 
how to arrange annotated tags to allow "git describe" to give the sort of 
monotonic version number some contributors want.

A reasonable starting point for hooks would be that they closely 
approximate what the current SVN hooks do for commit mails to gcc-cvs and 
for Bugzilla updates, as what the current hooks do is clearly OK at 
present and we shouldn't need to entangle substantive changes to what the 
hooks do with the actual conversion to git; we can always discuss changes 
later.

-- 
Joseph S. Myers
joseph@codesourcery.com