I've succeeded in using git svn with the Apache git mirrors, including rename tracking.

I started with http://wiki.apache.org/general/GitAtApache on a clone of the official mirror, and added a remote for my github fork of that repository. When I was done, git remote -v yielded:

fork	git@github.com:benson-basis/lucene-solr.git (fetch)
fork	git@github.com:benson-basis/lucene-solr.git (push)
origin	git@github.com:apache/lucene-solr.git (fetch)
origin	git@github.com:apache/lucene-solr.git (push)

Next, I made a branch to work in:

    git checkout -b LUCENE-LUCENE-5449-whatever

I made the changes, which included refactoring to rename some classes.

Next, I pushed the changes to my github fork.

    git push -u fork

Next, I made a pull request. By putting the JIRA tag in the PR title, I got the ASF git-bot to notice it and annotate the JIRA. Review ensues. Now it was time to actually commit to svn.

I'm very skittish of trying to use 'git merge' to move changes to svn; the git svn doc has discouraged it in the past, and a bit of thought about what git svn is trying to do left me feeling that it did not make a lot of sense. Instead, starting from a hint from Thomas Matthijs, I turned to git cherry-pick.

Git cherry-pick makes a new, non-merge, commit that applies the changes from some other commit.

Looking at my pull request, I could see that it was made up of two commits:

  8d62921596eb4e2799805582907b3bac546878b2 e7010a23a48075d4117f4ca826c1516b7e14ccd6

So,

    git checkout trunk # the tracking branch for origin/trunk
    git cherry-pick 8d62921596eb4e2799805582907b3bac546878b2 e7010a23a48075d4117f4ca826c1516b7e14ccd

This created two commits on the git-svn-enabled trunk branch.

Next, make sure that I'm up to date with other changes to svn.

    git svn rebase

And now to push the changes:

    git svn dcommit -M

The -M is critical; it instructs git svn to detect renames/moves and commit them to svn as such.

Note that git svn creates one svn commit for each git commit. If I wanted this to show up in svn as just one commit, I could have used git rebase on my branch to repack into one commit before I cherry-picked.

Now, there's one thing missing from the sequence: closing out the pull request. The ASF bot closes pull requests when it sees an svn commit message like:

    This closes #36.

Since that message wasn't in any of my git commit messages, it wasn't in svn.

My solution on this occasion was to notice that I'd forgotten CHANGES.txt. So, I made a vanilla svn commit, no git involved, to add this change to CHANGES.txt, and included the message. I could have also done this via git svn in the trunk.

For anyone considering following these footsteps, I recommend trying out git svn at a safe distance from the main Lucene branches to get some familiarity.

If you want to apply this workflow to a patch request from a non-committer, you would:

  • add a remote for the submitter's fork
  • cherry pick the submitter's commits
  • No labels