Junio C Hamano <junkio@xxxxxxx> wrote:
> Eric Wong <normalperson@xxxxxxxx> 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
-
: 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