Re: RFC: Patch editing

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Feb 27, 2007, 22:37 UTC
Message-ID: <Pine.LNX.4.63.0702272332440.22628@wbgn013.biozentrum.uni-wuerzburg.de>
In-Reply-To: <Pine.LNX.4.64.0702271651500.6485@iabervon.org>

Hi,

On Tue, 27 Feb 2007, Daniel Barkalow wrote:

Show 26 quoted lines

> 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