All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Daniel Barkalow <barkalow@iabervon.org>
Cc: git@vger.kernel.org
Subject: Re: RFC: Patch editing
Date: Tue, 27 Feb 2007 23:37:15 +0100 (CET)	[thread overview]
Message-ID: <Pine.LNX.4.63.0702272332440.22628@wbgn013.biozentrum.uni-wuerzburg.de> (raw)
In-Reply-To: <Pine.LNX.4.64.0702271651500.6485@iabervon.org>

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

  reply	other threads:[~2007-02-27 22:37 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-25 21:59 RFC: Patch editing Johannes Schindelin
2007-02-26 13:18 ` Peter Baumann
2007-02-26 18:03 ` Shawn O. Pearce
2007-02-26 18:52   ` Johannes Schindelin
2007-02-26 18:56     ` Shawn O. Pearce
2007-02-26 19:51       ` Junio C Hamano
2007-02-27  7:14 ` Daniel Barkalow
2007-02-27 11:54   ` Johannes Schindelin
2007-02-27 17:35     ` Daniel Barkalow
2007-02-27 20:07       ` Johannes Schindelin
2007-02-27 22:07         ` Daniel Barkalow
2007-02-27 22:37           ` Johannes Schindelin [this message]
2007-02-28 10:13           ` Karl Hasselström
2007-03-01 23:30 ` Updated version, was " Johannes Schindelin
2007-03-01 23:59   ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.63.0702272332440.22628@wbgn013.biozentrum.uni-wuerzburg.de \
    --to=johannes.schindelin@gmx.de \
    --cc=barkalow@iabervon.org \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.