From: Junio C Hamano <junkio@cox.net>
Date: Wed, 28 Jun 2006 09:25:29 GMT
Subject: Re: [PATCH 1/2] rebase: check for errors from git-commit
Message-ID: <7v1wt94oom.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <11514858662929-git-send-email-normalperson@yhbt.net>

Eric Wong <normalperson@yhbt.net> writes:

>  I've grown used to having 'set -e' at the beginning of my shell
>  scripts.  IMHO it'd be a good idea to start moving towards this
>  eventually (even though shell scripts seem to be getting phased-out
>  somewhat).
>
>  git-rebase.sh |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/git-rebase.sh b/git-rebase.sh
> index 9ad1c44..47c8e8f 100755
> --- a/git-rebase.sh
> +++ b/git-rebase.sh
> @@ -59,8 +59,8 @@ continue_merge () {
>  
>  	if test -n "`git-diff-index HEAD`"
>  	then
> +		git-commit -C "`cat $dotest/current`" || die 'Commit failed'
>  		printf "Committed: %0${prec}d" $msgnum
> -		git-commit -C "`cat $dotest/current`"

Anticipating failure from "git-commit" is the right thing to do,
but this is a "Now what?" situation.  What is the expected
course of action to recover from this for the end user, and how
can we phrase the error message to help that process?