Re: RFC: Patch editing

On Tue, 27 Feb 2007, Johannes Schindelin wrote:

Hi,

On Tue, 27 Feb 2007, Daniel Barkalow wrote:

quoted

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.

Essentially, yes.

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

That's true; I occasionally add some change that will go away in the next 
patch (or a later patch). This goes in between applying the cut-down 
patch and committing it (I also often build and test at this point, to 
make sure that my intermediate states work; so I can leave thing not 
working in the patch, and fix the build errors to generate the temporary 
intermediate state).

- 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.

One nice thing about my method is that, if you've had to make a dozen 
unrelated changes to get something to compile and run far enough to test 
whether any of the changes are actually correct, you can be sure to get 
that work preserved. I'd be a lot less comfortable preparing intermediate 
states if I didn't have the final state securely tucked away.

I don't really trust myself to not lose some partially-working state 
before I reach a state that's worthy of a commit, so I generate a lot of 
unworthy commits as part of the process of generating a state worth 
committing. I also sometimes want to use multiple computers in the course 
of reaching a state worthy of a commit; using git's state-distribution 
mechanism for that is really nice.

*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.

"git apply --index" actually recovers the information about added files.

	-Daniel
*This .sig left intentionally blank*