Re: rebase -i: Should --continue auto-amend after failed exec?

Johannes Sixt [off-list ref] writes:

If after a failed "exec" instruction there are staged changes, then currently rebase
--continue fails with:

.../git-rebase--interactive: line 774: .../.git/rebase-merge/author-script: No such file or directory

That's obviously bad, there should at least be an accurate error
message.

But shouldn't this amend the HEAD commit? The documentation is not clear
(from git-rebase.txt):

  The interactive rebase will stop when a command fails (i.e. exits with
  non-0 status) to give you an opportunity to fix the problem. You can
  continue with `git rebase --continue`.

This may be interpreted to work like "edit", and IMO would be a very useful
modus operandi.

I'm not sure. What happens in "edit" is that when reaching the "edit"
line, git-rebase--interactive.sh calls die_with_patch, which writes
author information in .git/rebase-merge/author-script, which really
means "I've stopped on this commit, this is the one that we should
implicitely amend with --continue".

The case of "exec" is a bit different: you don't stop "on a commit", but
after doing something else. You can hardly guess whether the staged
changes are meant to amend the existing commit, or to make a new one.

Actually, that could even be

pick deadbeef Existing commit
exec foo > bar.txt; git add bar.txt; git commit -m "added during rebase"
exec false
pick c00ffee Another commit

then auto-amending may be really confusing: should it amend the HEAD
commit that you've just created (this would really go against the logic
of .git/rebase-merge/author-script) or the last picked commit (which you
can't really do since it's not HEAD)?

I think it's best to abort, with an accurate error message pointing the
user to both solutions (commit --amend && rebase --continue or commit &&
rebase --continue). I'll try a patch.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/