From: Jonathan Nieder <jrnieder@gmail.com>
Date: Wed, 04 Apr 2012 20:16:10 GMT
Subject: Re: [PATCH] rebase -i: remove CHERRY_PICK_HEAD when cherry-pick failed
Message-ID: <20120404201610.GB17544@burratino>
In-Reply-To: <4F7C9FAE.5050806@sohovfx.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