GCC's Conversion To Git Is Still Turning Out To Be A Massive Headache

Remember earlier this month when GCC's long in the works conversion from SVN to Git was being held up by the lack of RAM on Eric S Raymond's system? Well, it turns out that's just part of the problem.

While earlier this month he thought he solved the last technical bug that was blocking the repository conversion and just needed more DDR4 RAM so his software could handle the complete GCC conversion into Git, that wasn't entirely the case. Recently he provided another update that began with, "That light at the end of the tunnel turned out to be an oncoming train."

While he thought the conversion process to Git for GCC was nearly complete, a more recent test conversion yielded incorrect content appearing on the trunk/master code-base. He went on to say, "That means that, under present assumptions, it's game over and we've lost. The GCC repo is just too large and weird...My tools need to get a lot faster, like more than an order of magnitude faster, before digging out of the bad situation the conversion is now in will be practical. Hardware improvements won't do that. Nobody knows how to build a machine that can crank a single process enough faster than 1.3GHz. And the problem doesn't parallelize."

One of Eric's last remaining ideas is to rewrite his "reposurgeon" code into Go from Python. He thinks that could yield around a 40x speed improvement. But he says converting his code from Python to Golang would be quite difficult. He ended that message with, "GCC management will have to make a decision about how patient it is willing to be. I am at this point not sure it wouldn't be better to convert your existing tree state and go from there, jeeping the Subversion history around for archival purposes."

Questioned about current GCC Git copies like gcc-mirror on GitHub and official-gcc.git, those are produced using the git-svn utility. Eric says those utilities can sometimes mess up branch joins and other corner cases.

In response to his message, a large number of the upstream GCC developers are simply calling for the conversion of the master/trunk code and recent branches like GCC 6/7/8 to be converted into Git while the older branches can be left as-is in read-only SVN or the git-svn'ed state. Though according to ESR, his reposurgeon utility recently hit a bug with the conversion of the trunk code, so that itself may first need to be bisected...

Hopefully by the end of the year, GCC will finally be centered around a Git workflow.