Subject: Re: [PATCH RFC v2 01/19] rebase -i: Failed reword prints redundant error message

From: Junio C Hamano <[email-masked]>
Date: Tue, 08 Jul 2014 13:31:13 -0700

Fabian Ruch <[email-masked]> writes:

> The to-do list command `reword` replays a commit like `pick` but lets
> the user also edit the commit's log message. If the edited log
> message is empty or is found ill-formatted by one of the commit
> hooks, git-rebase--interactive prints three error messages to the
> console.
>
>     1. The git-commit output, which contains all the output from hook
>        scripts.
>     2. A rebase diagnosis saying at which task on the to-do list it
>        got stuck.
>     3. Generic presumptions about what could have triggered the
>        error.
>
> The third message contains redundant information and does not add any
> enlightenment either, which makes the output unnecessarily longish
> and different from the other command's output. For instance, this is
> what the output looks like if the log message is empty (contains
> duplicate Signed-off-by lines).
>
>     (1.) Aborting commit due to empty commit message. (Duplicate Signed-off-by lines.)
>     (2.) Could not amend commit after successfully picking fa1afe1... Some change
>     (3.) This is most likely due to an empty commit message, or the pre-commit hook
>          failed. If the pre-commit hook failed, you may need to resolve the issue before
>          you are able to reword the commit.
>
> Discard the third message.
>
> It is true that a failed hook script might not output any diagnosis...

I think the message originally came from 0becb3e4 (rebase -i:
interrupt rebase when "commit --amend" failed during "reword",
2011-11-30); it seems that the primary point of the change was to
make sure it exits and the warning message may not have been well
thought out, but before discarding the result of somebody else's
work, it may not be a bad idea to ask just in case you may have
overlooked something (Andrew Wong Cc'ed).

> but then the generic message is not of much help either. Since this
> lack of information affects the built-in git commands for commit,
> merge and cherry-pick first, the solution would be to keep track of
> the failed hooks in their output so that the user knows which of her
> hooks require improvement.
>
> Signed-off-by: Fabian Ruch <[email-masked]>
> ---
>  git-rebase--interactive.sh | 3 ---
>  1 file changed, 3 deletions(-)
>
> diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
> index 7e1eda0..e733d7f 100644
> --- a/git-rebase--interactive.sh
> +++ b/git-rebase--interactive.sh
> @@ -506,9 +506,6 @@ do_next () {
>  		do_pick $sha1 "$rest"
>  		git commit --amend --no-post-rewrite ${gpg_sign_opt:+"$gpg_sign_opt"} || {
>  			warn "Could not amend commit after successfully picking $sha1... $rest"
> -			warn "This is most likely due to an empty commit message, or the pre-commit hook"
> -			warn "failed. If the pre-commit hook failed, you may need to resolve the issue before"
> -			warn "you are able to reword the commit."
>  			exit_with_patch $sha1 1
>  		}
>  		record_in_rewritten $sha1