From: Avery Pennarun <apenwarr@gmail.com>
Date: Wed, 23 Jul 2008 15:53:53 GMT
Subject: Re: [PATCH] rebase -i: only automatically amend commit if HEAD did not change
Message-ID: <32541b130807230853y136f41bdmf221637e35d601c3@mail.gmail.com>
In-Reply-To: <20080723120104.GQ2925@dpotapov.dyndns.org>

On 7/23/08, Dmitry Potapov <dpotapov@gmail.com> wrote:
> On Tue, Jul 22, 2008 at 06:22:34PM -0400, Avery Pennarun wrote:
>  > This patch is perhaps a symptom of something I've been meaning to ask
>  > about for a while.
>  >
>  > Why doesn't "edit" just stage the commit and not auto-commit it at
>  > all?  That way an amend would *never* be necessary, and rebase
>  > --continue would always do a commit -a (if there was anything left to
>  > commit).
>
> Actually, it would be better to refuse to continue if there are unstaged
>  changes in the work tree, and if all changes are staged then just do git
> commit.

I'm not sure about that.  The auto-committing on --continue has never
annoyed me, and in fact I greatly appreciate that I can just "git
rebase --continue" after making changes and the expected thing will
happen.  After all, if I screw it up and commit too much at once, I
can always just rebase one more time.

However, taking out the auto-commit wouldn't pain me too much if
others want it that way.  It would be somewhat more typing, but at
least makes easy to understand exactly what's going on.

> It would not only save typing, but also help to avoid costly mistakes
>  where users, being taught to use "git commit --amend" after editing
>  during git-rebase, fire this command automatically after a conflict
>  resolution and get two commits accidently squashed.

Yes!  Good point.  I forgot about this, but I've been bitten by it a
couple of times.

Have fun,

Avery