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@xxxxxxxxxxx
www.treskal.com/kalle
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html