Moving to Git
At the 2019 GNU Tools Cauldron we agreed that GCC should move to Git. The underlying feeling was that we've waited long enough (too long for many).
This page attempts to capture the schedule and the things that need addressing as part of that change. At this time the dates are subject to change
Select conversion method
SVN repository goes read-only (end of Stage 3)
Git repository goes live (approx 2 days after SVN goes read-only)
For logistical reasons, it may be necessary to slip the read-only date by a few days; but it will only be a few days.
The master repository for GCC will move to Git. All other processes and policies will remain unchanged at this time unless it forms a critical aspect of converting. In particular the patch review process and the policy for writing ChangeLog entries will not change at this time (these may be reviewed at a later date).
Selecting the conversion
We currently have three candidate conversions of the SVN repository to GIT:
- The existing Git mirror
MaximKuvyrkov's conversion script
- ESR's conversion via Reposurgeon
Each has its advantages and disadvantages.
Existing Git mirror
- Already converted, is syncing existing updates from SVN automatically
- Preserves SHA commits for those already working from the conversion
- Little to do to make this the master
- Based on git-svn which has some known problems with dealing with the old CVS-to-SVN conversion
Missing or incorrectly converted branches when they were put into branches/subdirectory/branch.
- Historical committer ID based on userid on FSF or GCC host machine (with some conflicts)
- Only a few select tags are present
Maxim's conversion scripts
- Complete conversion of all branches and tags (all descendants of trunk@1).
Historically-accurate mapping of author and committer names and emails (based on ChangeLog and commit log entries).
- All tags are converted to Git's annotated tags.
- Still based on git-svn technology.
- Hairy, undocumented scripts.
- Strictly follows SVN history. If there's an artifact from CVS to SVN conversion, then the same artifact will be in Git conversion.
- Best known conversion tool
- Can support special conversion rules for dealing with odd-ball commits
- Good handling of committer IDs
- Python version is very slow, requires a large machine to run the conversion (128GB plus fast CPU).
- Python version has a (critical) conversion bug that due to slow conversion performance is very difficult to track down and fix
GoLang version is not yet finished (though reportedly approaching completion).
We will pick the best conversion available at the selection deadline, based on the following criteria:
- Most converted branches
- Best support for committer data (names, email etc)
- Best support for CVS era data
A conversion candidate will be eliminated unconditionally if the HEAD revision of any critical branch (trunk, release branch or live development branch) does not match the head revision of the SVN copy of the branch
A number of additional tasks will need to be done before we can transition
WWWDocs - updates to pages describing how to contribute to GCC
Branch naming policies - user, vendor, development and release branch naming conventions
Update release management and snapshot scripts, test on a trial conversion of the repository