Re: RFC: Patch editing

On 2007-02-27 17:07:11 -0500, Daniel Barkalow wrote:

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?

My usual workflow looks like this too. I start out with a rough plan
of how to accomplish my goal with a number of smaller changes, but it
always turns out that I need more debug code, need to fix old bugs in
the middle of the process, need to fix silly bugs in earlier commits
in the series I'm building, and so on. I record this work with lots of
small commits. When I'm done, and usually at some intermediate stages
as well, I coalesce and reorder these commits to get a history
resembling my initial plan.

StGit is really helpful here. It doesn't actually do anything I
couldn't do manually with just git, but it makes it _simple_, and
tracks all the metadata for me so that I don't get a chance to make a
mess of things.

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle