2011/11/8 Glyph Lefkowitz <glyph@twistedmatrix.com>
I should stress that the most pressing problem here is not necessarily to provide a comprehensive, elaborate, automatic mirroring setup, but rather to provide canonical, correct, convenient instructions to people who are submitting tickets for review, and who want to use git for development. Ideally these instructions would not end up knocking over our version control server, either :). Right now, patches from git users show up in a variety of states of confusion and disarray: they're either based on an incredibly ancient version of trunk, or they're on a non-master branch of some repository and they don't say that, or they include 'a/' and 'b/' prefixes (i.e. they're -p1 patches when they should be -p0 according to the submission standard).
This is increasingly frustrating for me as a reviewer. I've got git installed; I don't even mind running a git command or two in the process of doing a review. But I would really like to get our submission standards straight so that the patches and branches that show up for review are something I (and others) can sensibly apply.
I am about to go out of town, but when I get back (December) I will have a go at this
if no one else has done so already.
Every time in the past when I have attempted to make a git clone of the Twisted repository,
git has complained that the Twisted svn repo is corrupt in some way. If there is already a
reliable bzr mirror of Twisted, it might be easier to base the git repo on that instead. Does
that seem feasible?
dave