From: Eric Wong <normalperson@yhbt.net>
Date: Wed, 28 Jun 2006 09:33:22 GMT
Subject: Re: [PATCH 1/2] rebase: check for errors from git-commit
Message-ID: <20060628093322.GA29036@hand.yhbt.net>
In-Reply-To: <7v1wt94oom.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano <junkio@cox.net> wrote:
> 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?

I would expect git-commit to show the correct error message (or the
pre-commit hook), die "$RESOLVEMSG" might be a better option, though.

-- 
Eric Wong