Re: [PATCH] rebase -i: remove CHERRY_PICK_HEAD when cherry-pick failed

[Jonathan Nieder <jrnieder@gmail.com>]

Andrew Wong wrote:

>                            Since there could be other scenarios where
> "commit" could fail

As far as I can tell, there just aren't any such other scenarios,
unless you mean like running out of memory or disk space.  "git
cherry-pick" disables hooks when running "git commit" so the
pre-commit hook can't block the commit.

So the scenarios fall into three or so categories.

 - when "git cherry-pick" performs a merge and encounters conflicts,
   it prints a message and exits, writing CHERRY_PICK_HEAD to tell
   the operator what command to use (instead of "git commit" or
   "git cherry-pick --continue") when the problem is resolved.

   If my script sets GIT_CHERRY_PICK_HELP, it will print a different
   message and does not write CHERRY_PICK_HEAD because the operator
   is going to run "myscript --resume" and not "git commit" or "git
   cherry-pick --continue" when the problem is resolved.

 - when "git cherry-pick" performs a clean merge that produces no
   change, "git commit" prints a message about a missing --allow-empty
   argument and exits.

   My GIT_CHERRY_PICK_HELP setting is not respected, so the user is
   likely to run "git commit" or "git cherry-pick --continue" instead
   of the command I wanted.

 - when "git cherry-pick" performs a clean merge that produces a
   change but "git commit" fails to record it due to a stray signal or
   running out of disk space, git does not print any advice for the
   operator.

   In particular, my GIT_CHERRY_PICK_HELP setting is not respected.
   Also, CHERRY_PICK_HEAD is written even though my wrapper script
   that sets GIT_CHERRY_PICK_HELP didn't expect that.

   The operator can return to a familar state with "git reset --hard"
   followed by "git checkout" of some familiar branch, except that my
   script may be keeping some state of its own that lingers until the
   operator tries to use it again...

I was focusing on the second category.  Using a stock message instead
of the custom message from GIT_CHERRY_PICK_HELP certainly seems to me
like a bug or incomplete feature.

When you say that there are other ways for "git commit" to fail and
Junio says that in some cases "git cherry-pick" should not write
CHERRY_PICK_HEAD at all, you are probably thinking of the third
category.

Hope that helps,
Jonathan