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

2 messages, 2 authors, 2021-08-05 · open the first message on its own page

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.

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

From: ZheNing Hu <hidden>
Date: 2021-08-05 05:35:59

Junio C Hamano [off-list ref] 于2021年8月5日周四 上午1:31写道:
Phillip Wood [off-list ref] writes:
quoted
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 ...
quoted
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.
Well, this is indeed a bit strange, but maybe your and Phillip's
intuitions are right,
then I will delete the content of the first patch and keep the second.
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.
Thanks.
--
ZheNing Hu
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help