Hi, On Tue, 27 Feb 2007, Daniel Barkalow wrote: > On Tue, 27 Feb 2007, Johannes Schindelin wrote: > > > 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. Same for me. > 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; Still same for me. > version that's buggy but verbose; I don't commit that. However, if I _do_, it _only_ contains the messages. And in that case rebase--interactive (this is the new working title for edit-patch-series) allows you to just kill these commits... > version that's working but verbose. Would be handled by (3way) cherry-pick. > Am I unusual in being afraid of losing work in a state that contains 3 > different half-features? Not at all. I often do "git checkout -b temp && git commit -a -m temp && git checkout <oldname>". Ciao, Dscho - 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