Thread (7 messages) flat view 7 messages, 4 authors, 2016-06-15

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

From: Avery Pennarun <hidden>
Date: 2016-06-15 22:45:00

On 7/23/08, Dmitry Potapov [off-list ref] 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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help