Hi, On Tue, 27 Feb 2007, Daniel Barkalow wrote: > For much the same reason, I wrote a script that entirely ignores the > intermediate commits in a throw-away head, and lets you trim down the > diff between the mainline and your head, and arrange it into a new patch > series. It looks to me like you just start a new branch, get the state of an existing commit *1*, and then "git add -i" your way through that diff. This is slightly different from my work flow: - I can have overlapping changes (i.e. one commit fixes something which gets refactored in the next), and - I try not to touch the code when editing the patch series. Only in the conflicting case, I _have_ to edit it. The latter means, of course, that the commits in the throwaway branch _must_ be a superset of the commits I want to have in the cleaned up branch. (Meaning that I never commit two unrelated things with the same commit.) To achieve that, I use my own version of "git add -i" quite often while composing the throwaway branch. For example, when I found a bug with an easy fix, in the middle of something different, and the fix touches a file that is already changed, I only commit the appropriate hunks of that file. Ciao, Dscho *1* It is not really as easy as "git diff ..other-branch | git apply", since you would lose valuable information about added files, so you have to be very careful there. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html