Re: Moving to git

[Joseph Myers <joseph at codesourcery dot com>]

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