Version 8 (modified by Screwtape, 7 years ago) (diff)

Add some more details about how to create a git svn clone of the SVN repo.

A Git mirror of the entire Twisted repository is available.

Checking out the official mirror

git clone

Note that even if you have Twisted commit access, you can't create or merge branches this way — you must create your own git svn clone (see below).

Since you've cloned an ordinary Git mirror, you'll need to keep it up to date with git fetch.

Creating a mirror

Note 1: Do not do this unless you are a Twisted developer and have asked permission. As of early 2010, this procedure takes about a week (YES, A WEEK) to run.

Note 2: This command hasn't yet been run for long enough to see whether it produces a properly-configured, working git svn clone. However, it's our best guess so far.

git svn clone --stdlayout --prefix="svn/" svn+ssh://

Issues with this command that need to be researched/addressed:

  • Apparently revision 2 creates a branch called "Glyph", which I can't find in the SVN browser in Trac. Not quite sure what's going on there.
  • My vague recollection is that there's some old, closed branches which cause problems for git svn because their names contain odd punctuation which gets doubly-URL-escaped somewhere... specifically, there's one branch that got created a number of different times because SVN couldn't really handle it either. Since they're old and closed, they can probably be ignored with the --ignore-paths=<regex> option.

Once the new mirror has completed construction, you can keep it up-to-date with git svn fetch.

Configuring your Git repository

Once you have a proper Git repository of the Twisted source, you'll need to configure it a little.

Git isn't ignoring .pyc files!

There is no .gitignore in the repository. This is intentional — there's no svn:ignore properties in the official SVN repository either — on the grounds that different people might want to ignore different things. Instead, you can tell Git to ignore things by adding rules to the .git/info/exclude file. Here's an example:


See the Git documentation on .gitignore, particularly core.excludesfile, for more information.

Configuring git to produce SVN-style patches

A patch file contains a section for each affected file, describing the changes to that file. The header for that section includes the name of the file, and by default the header for a change to path/to/file looks like this: {{{ diff --git a/path/to/file b/path/to/file }}}

The "a/" and "b/" prefixes are added by git, but SVN doesn't do that, and many Twisted developers have tools that only handle SVN-style patches. To make Git produce SVN style patches just for the Twisted repository, run the following command from inside the repository: {{{ git config --bool --add diff.noprefix true }}}

git svn operations seem to take forever

If you have your own git svn clone, and svn-based operations seem to take forever, try running:

git svn info

If that takes longer than 30 seconds to run, and eventually prints an error message, this is a clue that git svn has gotten confused about how your current branch connects to the imported SVN history. Either git checkout a git branch that's based on an SVN branch or (if you're already on such a branch, and it's broken) use git reset some-remote-branch-name to make sure your local branch is pointing exactly at a commit that was imported from SVN.

git svn branching

Follow the standard Twisted branch-name conventions when creating branches with Git. In the following example, $BRANCH_NAME means the name of the branch you're trying to create.

# Create "branches/$BRANCH_NAME" in the central SVN repository.
git svn branch $BRANCH_NAME

# Create and checkout local branch "$BRANCH_NAME" that tracks "remotes/$BRANCH_NAME"
git checkout -b $BRANCH_NAME remotes/$BRANCH_NAME

git svn committing

No special rules apply about making Git commits, you can make as many commits as you like, then rebase them into a nice patch series as normal (although the Twisted review process generally reviews the diff of an entire branch, not individual commits, since rebasing isn't possible in SVN).

However, once you send your patches to the central SVN server with git svn dcommit, be very careful about messing with them. Don't rebase any further back than the last push, or else the next dcommit is likely to go awry.

Likewise, if you merge from trunk to branch, then dcommit the merge, it will become an ordinary commit that doesn't remember its ancestry, and merging it back onto the trunk later is likely to cause grief. So don't do that.

git svn merging forward

I haven't done this yet, but it probably needs special handling for the reasons mentioned in the previous section. Look at the official how-to-merge-forward docs for inspiration.

git svn branch merging

In the following example, $BRANCH_NAME means the name of the branch you're trying to merge to trunk.

# Check out the trunk (what git calls 'master'), make sure it's up-to-date.
git checkout master
git svn fetch && git svn rebase

# Apply all the changes on the branch to the trunk as one change set.
git merge --squash remotes/$BRANCH_NAME

# Commit the change set. Remember to use the Canonical Merge Commit Message Format!
git commit

# Push the commit to the central SVN repository.
git svn dcommit

By "Canonical Merge Commit Message Format", I mean the example merge commit message in the Working From Twisted's Subversion Repository documentation.