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

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

 



Fabian Ruch <bafain@xxxxxxxxx> 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 <bafain@xxxxxxxxx>
> ---
>  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
--
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]