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* - 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