Re: RFC: Patch editing

[Daniel Barkalow <barkalow@iabervon.org>]

On Tue, 27 Feb 2007, Johannes Schindelin wrote:

> Hi,
> 
> On Tue, 27 Feb 2007, Daniel Barkalow wrote:
> 
> > 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.
> 
> You _could_ still ensure that by looking in the reflog which was your old 
> tip-of-branch, and git-diff with that.
> 
> But I agree. That is why I commit _everything_ before rearranging.

I think you're misunderstanding me; I want to use git's 
archival/distribution functionality before I have a commit that I can put 
a useful message on. This means that, at some point, I'm making real 
commits, and I know what final state I want, but that final state involves 
unrelated changes.

I think I usually come up with something like: 7 patches related to the 
functionality I'm working on, 1 patch that fixes an old bug that became 
important due to the change, and 2 patches which improve the debugging 
infrastructure. And the actual sequence of intermediate states that my 
code was in is something like: API written, stub implementations, some 
code that suggests what should happen; program calling the API and 
crashing; version that is written but buggy; version that's buggy but 
verbose; version that's working but verbose. In refining the work, I drop 
or "if (DEFINED_TO_0_DEBUG)" the messages, split out the patches that 
support the new kinds of messages, and include only working versions of 
functions. And then I write commit messages that talk about the code and 
sign them.

Am I unusual in being afraid of losing work in a state that contains 3 
different half-features?

	-Daniel
*This .sig left intentionally blank*