On Thu, 9 Jan 2020, Joseph Myers wrote: > Here's a test conversion with the conversion machinery in what should be > essentially final form. This is like the "b" versions (dead and vendor > branches present but not fetched by default), with the addition of refs > from the existing git mirror as refs/git-old/* and refs/git-svn-old/* (not > fetched by default). > > git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-8.git
Hooks are now set up and ready for testing commits to this repository, including integration with gcc-cvs and libstdc++-cvs mailing lists and Bugzilla. I recommend only referencing test bugs you open for the purpose in commits, not real bugs, to avoid confusing people, as the messages that end up in Bugzilla don't make it obvious that this is a test conversion (the messages on the -cvs mailing lists are more obvious, as they say "gcc-reposurgeon-8" in their subject headers). Commits made in this repository will not end up in the real conversion. gitweb URLs in messages from this conversion won't actually work, because they point to the real gitweb (which currently points to the git-svn mirror). All commits should generate commit emails. Only commits to master and release branches should generate Bugzilla updates. master and release branches do not allow merge commits, other branches do. Branches in refs/users/<user>/heads and refs/vendors/<vendor>/heads allow non-fast-forward pushes and branch deletion, other branches don't. Branch updates or new branches based on the history from the git-svn mirror (with 3cf0d8938a953ef13e57239613d42686f152b4fe, the initial git-svn commit, in their ancestry) are disallowed; this avoids someone accidentally pushing such a branch to a namespace that git fetches by default and causing everyone to fetch a GB of extra history as a result. Thus, for continued development based on such a branch you should start by rebasing (not merging) onto the new version of the history, and then the rebased branch can be pushed to one of the supported namespaces (under refs/users/<user>/heads/ if treating it as a user branch, under refs/heads/devel/ for a development branch that gets fetched by default). The hook configuration is something that seemed reasonable as a starting point, not necessarily what we will have as the final configuration. The configuration file for the AdaCore hooks is project.config on the refs/meta/config branch (but there are local patches to those hooks at present, and as with other refs, changes to refs/meta/config will not persist to the final converted repository). -- Joseph S. Myers jos...@codesourcery.com