On 2009.01.15 23:59:12 +0100, SZEDER Gábor wrote:
quoted text
> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html