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

From: Fabian Ruch <[email-masked]>
Date: Thu, 10 Jul 2014 18:35:08 +0200

Hi Andrew,

thanks for your review and sorry that I forgot to cc the bug fix to you.

Andrew Wong writes:
> On Tue, Jul 8, 2014 at 4:31 PM, Junio C Hamano <[email-masked]> wrote:
>> Fabian Ruch <[email-masked]> writes:
>>> 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.
> 
> Since "git commit" already prints out error messages for failing due
> to empty commit message, the third message is really about giving
> hints in the case where pre-commit fails. We could probably assume
> that pre-commit would also print out error messages. So I'd be fine
> with removing the third message. But I wonder if we need to explain
> that the user needs to run "git rebase --continue" to resume the
> rebase?

That is still taken care of by exit_with_patch here. When called in the
error case, it prints

    You can amend the commit now, with

    	git commit --amend

    Once you are satisfied with your changes, run

    	git rebase --continue

to standard error. I might have overlooked this in one of the later
patches though.

   Fabian