How to dcommit only selected patches with git svn?

Question

I have a number of locally committed patches in my git-svn repo which I haven't yet commited to our svn repo. A normal "git svn dcommit" will commit all of these patches to svn. I would like to commit only some of my patches (simple bug fixes), but not others (untested major changes). How can I do this with git svn?

Answer 1

I've been following the procedure here:

http://fredericiana.com/2009/12/31/partial-svn-dcommit-with-git/

If you're comfortable rebasing, it works pretty well.

Answer 2

Here's what I ended up doing. The starting point is the "master" branch synced with svn, with all of my local patches on top.

1. Create a new branch (wip = Work In Progress).

   git branch wip 
   

   This makes a copy of the current branch, including all patches not yet committed to svn. The current branch will stay as "master" and will not be changed.

2. Remove the unwanted local patches from "master" with a rebase:

   git rebase -i HEAD~10
   

3. Now the "master" branch has patches you can safely commit:

   git svn dcommit
   

   The "wip" branch now has the major changes which aren't yet ready for sharing. Actually, I want them to stay there and this is where I would stop. It's possible to do the svn dcommit from the "wip" branch once everything is finalized. But for completess' sake, and to answer the original question, there's a final step:

4. Pull the uncommitted changes back to the "master" branch using git cherry-pick and finally remove the useless branch with git branch -d wip.

Answer 3

With git, you're not actually supposed to operate on single changesets. The best approach I know is to create local branches for any non-trivial work. This way, your untested major changes will end up in different branches of your git repository, and you'll be able to differ them quite easily.

If this is the problem you have at the moment you can probably create create a new branch from the point you last updated from svn and then use git-cherry-pick to transfer your simple bug fixes to this new branch, from which you can then dcommit to svn.

From a more long-term point of view it's best to have your own "master" branch made from subversion trunk, and then either:

1. Rebase all your branches every time you update from svn, then merge those you want to get to svn to your master and dcommit from there.
2. Merge stuff from svn using regular git-merge, and then merge stuff to your master for dcommits by git diff ..my_branch | patch -p1, which will eliminate history that git-svn can't handle. This approach is more complicated for the final merging but allows you to merge stuff between branches (and possibly other people) in git itself.