On 08/20/2015 04:33 PM, Joseph Myers wrote:
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.
Thanks for the pointers, that all makes sense.
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.
Yes.
* 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.)
Agreed.
* 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).
Yes, this is already the case for the git-svn mirror.
* 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.)
This is also currently the policy of the git-svn mirror.
* Do we want the hooks disallowing trailing whitespace on new / modified
lines? (I'd be inclined to say yes.)
I'm not sure how many people would care about this without git nagging
them, but sure.
* 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.)
I don't read gcc-cvs, so I don't have an opinion about this. I wouldn't
expect it to be useful, but presumably binutils-gdb have a reason for
doing it.
* 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.
Absolutely.
* 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.
Agreed.
* Make sure whatever process updates the github mirror is kept going after
the conversion (actually it looks like it broke two weeks ago...).
I have no idea how this mirror is updated. Its github page is
remarkably uninformative.
* 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.)
Hmm, the wwwdocs repository has very little in common with the GCC
repository, but I guess it could be useful for testing hooks, as you say.
Jason
