On Thu, 20 Aug 2015, Jason Merrill wrote: > It should be pretty straightforward to use the existing git mirror as the > master repository; the main adjustment I'd want to make is rewriting the
I think using the existing git mirror for this is a bad idea. To quote <http://esr.ibiblio.org/?p=6778>: "Use git-svn for live gatewaying if you must, remaining aware that it is not the safest tool in the world. But for a full conversion use a dedicated importing tool.". I think a proper conversion to git as the master repository should reconvert all the history with author ids properly mapped and subdirectory branches properly handled as such throughout the conversion. (I don't think other oddities are worth cleaning up unless it's easy to e.g. clean up cvs2svn oddities in the conversion process, or unless someone is particularly keen on cleaning them up, and don't think any attempt should be made to rewrite existing commit messages. And if using reposurgeon, I think its special handling of svn:ignore and .cvsignore should be disabled, keeping .cvsignore in older history and our existing .gitignore in newer history as we already have a well-maintained .gitignore file - that way maybe git tags can keep contents identical to the corresponding SVN tags.) The two histories could then be combined in a single git repository by renaming all the existing refs in the git repository not to conflict with those from the proper conversion, and if desired adding a merge commit on master to converge the two histories. The two histories would share blob objects and hopefully tree objects as well (but of course not commit objects), so this shouldn't increase the space taken up by too much. > It would be good to have a more explicit policy on branch/tag creation, > rebasing, and deletion in the git world where branches are lighter weight and > so more transient. In general, we should have updated versions of all documentation relating to the use of the repository (that's mainly svn.html and svnwrite.html), and of scripts in maintainer-scripts, before doing the final move. * Policy on commit messages, as already discussed (though I'd say that generally the substantive part of the gcc-patches message about the patch is useful to include as well as the ChangeLog entry). (This policy would only be for master and official release branches; for other branches it would be up to the people using them.) * As standard for shared repositories, hooks should disallow any non-fast-forward pushes (this means you can't rebase and then push to the same branch without deleting it in between). * Decide whether to allow branch deletion. If so, I'd say it should only be for branches inside personal / company namespaces. (If a branch is simply obsolete, don't remove it.) * Do we want the hooks disallowing trailing whitespace on new / modified lines? (I'd be inclined to say yes.) * Do we want hooks to send diffs to gcc-cvs as well as commit messages? (binutils-gdb uses hooks that do that with size limits on the amount of diffs sent.) * In the common case where you try to push a commit and find that someone else committed to master so the push fails, you should git pull --rebase rather than plain git pull before pushing again, so the history on master remains linear in such cases; merge commits on master, if any, should be limited to merges of more substantial development branches. * Specifically do not associate any changes in workflow with the move to git. Exactly the same release branching and development arrangements would be used, ChangeLog files would continue to be updated manually. If someone wishes to (say) set up arrangements for generating ChangeLogs at release time rather than putting entries in them at commit time, that should be something completely separate after the move to git. * Make sure whatever process updates the github mirror is kept going after the conversion (actually it looks like it broke two weeks ago...). * I encourage using the wwwdocs repository as a test-bed for the conversion. Its history is so much simpler that once you have the author map worked out, almost any tool would probably produce a good conversion, and such a conversion could be used to test hooks before converting the main repository. (I expect in any case that a few trial conversions of the main repository would be needed for people to review before we're ready for the final conversion. wwwdocs would be a reasonable test-bed for hooks, but not for conversion complications.) -- Joseph S. Myers jos...@codesourcery.com
