Re: RFC: Patch editing

On Tue, 27 Feb 2007, Johannes Schindelin wrote:

Hi,

On Tue, 27 Feb 2007, Daniel Barkalow wrote:

quoted

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*