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 <gits...@pobox.com> wrote:
>> Fabian Ruch <baf...@gmail.com> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
