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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Johannes Sixt <j6t@xxxxxxxx> 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/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]