Thread (2 messages) flat view 2 messages, 2 authors, 2021-08-05

Re: [PATCH v2 1/2] [GSOC] cherry-pick: fix bug when used with GIT_CHERRY_PICK_HELP

From: Junio C Hamano <hidden>
Date: 2021-08-04 17:31:37

Phillip Wood [off-list ref] writes:
quoted
You mean that cherry_pick with GIT_CHERRY_PICK_HELP suppresses
CHERRY_PICK_HEAD is not even a bug?
I think that it is what the existing test is telling us.  Of course,
with a good reason, an earlier design can be updated as long as we
make sure we won't hurt existing users who may rely on the current
design, but ...
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.
... I think that is a reasonable stance to take [*1*].  If the
default help message can be improved, that is a good thing to do
regardless.

Thanks.

[Footnote]

*1* Tying the "here is a custom HELP text" environment variable to
"having a customization means whoever is driving the cherry-pick
machinery is ALSO responsible for sequencing and we will remove
CHERRY_PICK_HEAD" is a rather unfortunate design, but as long as
that is documented, it is a workable design.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help