patch, 2 partsRe: [PATCH 1/2] rebase: check for errors from git-commit

> 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?

> Junio C Hamano <junkio@cox.net> wrote:
>
>> 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 <normalperson@yhbt.net> writes:
> 
> > Junio C Hamano <junkio@cox.net> wrote:
> >
> >> 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.
> 
> It would say 'resolve conflicts, mark them with update-index as
> necessary, and say git-commit' or somesuch.  I am not sure you
> would want the user to make a commit like suggested -- instead
> you would want him to say 'git rebase --continue' wouldn't you?

> Junio C Hamano <junkio@cox.net> wrote:
>> Eric Wong <normalperson@yhbt.net> writes:
>> 
>> > Junio C Hamano <junkio@cox.net> wrote:
>> >
>> >> 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.
>> 
>> It would say 'resolve conflicts, mark them with update-index as
>> necessary, and say git-commit' or somesuch.  I am not sure you
>> would want the user to make a commit like suggested -- instead
>> you would want him to say 'git rebase --continue' wouldn't you?
>
> Actually RESOLVEMSG in git-rebase just tells the user about the
> --continue, --skip, --abort options.