Version 6 (modified by Screwtape, 4 years ago)

Make it clearer how branch-names are constructed.

A Git mirror of the entire Twisted repository is available.

Checking out

git clone

Note that even if you have Twisted commit access, you can't create or merge branches this way — you must use SVN directly, make your own Git mirror with git svn, or obtain a copy (not a clone) of such a Git mirror. If you do choose to make your own Git mirror with git svn, it takes about a week to import the entire Twisted commit history as of early 2010.

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.

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 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.