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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
--
To unsubscribe from this list: 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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]