Re: [PATCH] rebase -i: only automatically amend commit if HEAD did not change

From: Avery Pennarun <apenwarr@gmail.com>
Date: Jul 23, 2008, 15:53 UTC
Message-ID: <32541b130807230853y136f41bdmf221637e35d601c3@mail.gmail.com>
In-Reply-To: <20080723120104.GQ2925@dpotapov.dyndns.org>

On 7/23/08, Dmitry Potapov <dpotapov@gmail.com> wrote:

Show 12 quoted lines

> 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