Johannes Schindelin [off-list ref] writes:
NACK.
You just broke the 'edit' command.
Really? I thought it would be Ok for "edit" command.
The patch checks the presense of /amend and complains only if it does not
exist, while you create /amend when you respond to "edit" insn.
I was relunctant about the patch not because of "edit", but because I am
not convinced that it will _never_ make sense to be able to amend while
the sequence stops with a conflict (as the patch does not give us any way
to override this rather heavy-handed denial to continue).
I also was hoping that with enough hooks git-commit already calls, this
could have been experimented and implemented with hooks without touching C
layer at least initially, while people can convince themselves that the
approach is sane (i.e. it _never_ makes sense to do amend upon conflict).
On 6/25/08, Junio C Hamano [off-list ref] wrote:
I was relunctant about the patch not because of "edit", but because I am
not convinced that it will _never_ make sense to be able to amend while
the sequence stops with a conflict (as the patch does not give us any way
to override this rather heavy-handed denial to continue).
Perhaps the problem is more that people are encouraged to --amend so
often that they end up doing it by accident.
What if 'edit' worked more like 'squash', in that it produced the new
tree, but didn't commit it yet? Then you can reset things, commit
them, or rebase --continue (which commits automatically if needed)
just like wish 'squash'.
I think --continue used to not commit automatically, so I can see why
edit used to commit for you, but maybe that behaviour is not needed
anymore.
Right now the asymmetry of having to use --amend with 'edit' but not
with 'squash' is what leads me to make mistakes sometimes.
Have fun,
Avery
Hi Junio,
Please, do not apply my previous patch. I just realized that it will
break the following sequence of commands when you are stopped on a
conflicting commit during rebase:
$ edit file
$ git add file
$ git commit
$ git commit --amend
I don't see a good solution right now. Perhaps, the better approach
will be to remove the suggestion of using "git commit --amend" and
instead to recommend to use "git add" to add your changes and then
run "git rebase --continue". This works regardless whether you stop
on the "edit" mark or conflict. The only problem with that is what
if the user actually wanted to edit the commit message. Currently,
saying just "git rebase --continue" without adding anything will
not allow you to edit the commit message.
After studying git-rebase script, I noticed that it always commit
with the --no-verify option. It makes sense for those commits that
were just "pick" but IMHO those commits that were edited by users
probably should be commited in the normal way, so the pre-commit
hook can ensure that your changes are okay.
Dmitry