Yes, that's what I did (though with git rebase -i, not git merge -- git merge and git-svn don't get along at all). I cut about 50 commits down to 8 or 9 (the others are fixes to pre-existing bugs that I made along the way) to present a progression of related changes. This way the commit messages can explain what's going on in each changeset (rename files, replace module x, etc.) rather than having a single massive changeset that does a dozen things at once, and no way to separate which bits of the changeset implement what changes. It might complicate code review if you do it one changeset at a time, because (as in the instant case) you think of an improvement in one only to find that I did exactly that two changesets later, but if you're examining a file down the road and trying to understand what it does and why it's implemented the way it is, having an understandable history makes the task much easier.