On 04/08/2021 09:35, ZheNing Hu wrote:
Junio C Hamano <gitster@xxxxxxxxx> 于2021年8月4日周三 上午6:36写道：
Hmph, this is a bit troubling. So has this been part of the
"published" behaviour since d7e5c0cb (Introduce CHERRY_PICK_HEAD,
2011-02-19) that introduced this test, and there are people who are
relying on it? IOW, should the resolution to the original problem
report have been "if it hurts, don't do it" (in other words, "setting
GIT_CHERRY_PICK_HELP will remove CHERRY_PICK_HEAD, so if you do not
want to get the latter removed, do not set the former")?
You mean that cherry_pick with GIT_CHERRY_PICK_HELP suppresses
CHERRY_PICK_HEAD is not even a bug?
It is reasonable for `git rebase -p` and `git rebase -m` to delete
CHERRY_PICK_HEAD when a conflict occurs, but it is not necessarily
for git cherry-pick to delete it too. IOW, I suspect that instead of
letting users
not touch the trap here, it is better to remove the trap completely.
Looking at the history I think it is fair to conclude that
GIT_CHERRY_PICK_HELP was introduced as a way to help people writing
scripts built on top of 'git cherry-pick' like 'git rebase' that want to
have a custom message and do not want to leave CHERRY_PICK_HEAD around
if there are conflicts. I don't think it was intended as a way for users
to change the help when cherry-picking and has never been documented as
such. I think we'd be better to focus on improving the default help that
cherry-pick prints as the second patch in this series does.
Best Wishes
Phillip
Thanks.
--
ZheNing Hu
