Workflow for "rolling out" commits

Hi,

I spend a great deal of time preparing patches for the mailing list, and it's time I asked for help to optimize the process I'm using. I'll explain what I'm doing in detail, and why I'm doing it- I'd love it if someone could tell me how to do it better.

I work on two repositories: git.git and svn-fe.git. In svn-fe.git, we mainly work on `master`, occasionally forking out feature branches and merging them back. I also work on a certain `git-merge` branch that only has changes specific to getting svn-fe.git merged into git.git; it is based on `master` and constantly needs to be rebased everytime `master` updates. `master`, on the other hand, is intended to maintain and compile an independent application. To send patches to the mailing list, I have another branch `rollout` which is basically the `git-merge` branch stripped of revision history (the `git-merge` branch has thousands of commits, and I don't want this revision history to be part of git.git). In `rollout`, I have neatly added files logically and prepared six commits to send directly to the mailing list.

In git.git, I have a remote corresponding to svn-fe.git, and use git-read-tree with a prefix = $GIT_ROOT/vcs_svn to import the `rollout` branch from svn-fe.git into the vcs-svn/ directory (Thanks to Sverre I don't cherry-pick, git-mv and amend the commits one by one). I then use format-patch and send-email to send emails to the mailing list.

Whenever `master` updates, I first rebase `git-merge` onto `master`, copy out the new files from the `git-merge` working copy to the `rollout` working copy, make more commits to squash into the six existing commits in `git-merge`(*). Then I fetch the objects into git.git and import the tree again.

(*) I can theoretically automate this on a fresh `rollout` branch by using a shell script to add the files and make out commits one-by-one by picking up the commit messages from a text file.

Thanks for reading.

-- Ram