Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state

From: Björn Steinbrink <b.steinbrink@gmx.de>
Date: Jan 16, 2009, 00:11 UTC
Message-ID: <20090116001139.GA26357@atjola.homenet>
In-Reply-To: <20090115225912.GL9794@neumann>

On 2009.01.15 23:59:12 +0100, SZEDER Gábor wrote:

Show 14 quoted lines

> On Thu, Jan 15, 2009 at 11:20:08PM +0100, Sverre Rabbelier wrote:
> > On Thu, Jan 15, 2009 at 23:09, Junio C Hamano <gitster@pobox.com> wrote:
> > > I agree that is a true disadvantage that shows "reset --soft HEAD^" is a
> > > bad idea (you could still say commit -c @{1}, though).
> > 
> > But it's not:
> > "It also makes sure that a pre-filled editor is fired up when doing
> > "git rebase --continue", in case the user just wanted to fix the
> > commit message."
> 
> Indeed, but in this case the rebase process will continue after
> finishing the commit message.  OTOH, with the current behaviour, you
> must do a 'git commit --amend && git rebase --continue', which might
> seem more complicated at first sight, but...

No, you don't have to do that. As long as you only want to "edit" the commit you marked as "edit", you only need to use "git add" and "git rebase --continue". rebase -i checks whether HEAD still resolves to the same commit and if so, it automatically does the soft reset for you.

Maybe we should just advertise that in the message provided by rebase after it stops? I'm afraid I can't come up with a sane wording though, as there are still cases when you need to commit yourself, eg. when you use reset. And getting that into one simple sentence seems a bit hard (for me).

A bit off-topic: The "auto-amend" code path passes --no-verify to git commit. What's the reason for doing that? I actually always expected that to use my pre-commit hook to stop me from committing crap. :-/

Björn