# Re: [PATCH 1/2] rebase: check for errors from git-commit 4 messages from 2006-06-28 to 2006-06-28. Participants: Junio C Hamano, Eric Wong. Thread: https://gitlist.dev/t/4693 ## Eric Wong, 2006-06-28 09:33 Subject: Re: [PATCH 1/2] rebase: check for errors from git-commit Message-ID: <20060628093322.GA29036@hand.yhbt.net> URL: https://gitlist.dev/e/20060628093322.GA29036%40hand.yhbt.net In-Reply-To: <7v1wt94oom.fsf@assigned-by-dhcp.cox.net> ``` Junio C Hamano wrote: > Eric Wong 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 ``` ## Junio C Hamano, 2006-06-28 09:49 Subject: Re: [PATCH 1/2] rebase: check for errors from git-commit Message-ID: <7vveql38zr.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vveql38zr.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <20060628093322.GA29036@hand.yhbt.net> ``` Eric Wong writes: > Junio C Hamano 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? ``` ## Eric Wong, 2006-06-28 09:54 Subject: Re: [PATCH 1/2] rebase: check for errors from git-commit Message-ID: <20060628095454.GA23948@soma> URL: https://gitlist.dev/e/20060628095454.GA23948%40soma In-Reply-To: <7vveql38zr.fsf@assigned-by-dhcp.cox.net> ``` Junio C Hamano wrote: > Eric Wong writes: > > > Junio C Hamano 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. -- Eric Wong ``` ## Junio C Hamano, 2006-06-28 09:56 Subject: Re: [PATCH 1/2] rebase: check for errors from git-commit Message-ID: <7vmzbx38o1.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vmzbx38o1.fsf%40assigned-by-dhcp.cox.net In-Reply-To: <20060628095454.GA23948@soma> ``` Eric Wong writes: > Junio C Hamano wrote: >> Eric Wong writes: >> >> > Junio C Hamano 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. Yup, so telling the user to disregard what commit might say (but do not hide it by redirecting 2>/dev/null, please) and dying with "$RESOLVEMSG" might be a better way. ```