Re: RFC: Patch editing

From: Karl Hasselström <kha@treskal.com>
Date: Feb 28, 2007, 10:13 UTC
Message-ID: <20070228101315.GA18444@diana.vm.bytemark.co.uk>
In-Reply-To: <Pine.LNX.4.64.0702271651500.6485@iabervon.org>

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

Show 15 quoted lines

> 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