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 jos...@codesourcery.com
