> On Aug 24, 2019, at 12:30 AM, Joseph Myers <jos...@codesourcery.com> wrote: > > 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.
Could you upload GCC repo converted with reposurgeon somewhere public? And also list expected artifacts in its current version? >From my side, the machine on which the conversion ran ran out of disk space >about 3 weeks ago. I'll clean it up and restart the conversion updates. I'll also improve author entries a bit, so gcc-pretty.git's history will change ever so slightly. > > 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. Would the community please assign a volunteer for this at Cauldron? :-P Thank you, -- Maxim Kuvyrkov www.linaro.org
