ZheNing Hu wrote: > Junio C Hamano <gitster@xxxxxxxxx> 于2021年7月23日周五 上午5:25写道： > > > > "ZheNing Hu via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > > > > > From: ZheNing Hu <adlternative@xxxxxxxxx> > > > > > > If we set the value of the environment variable GIT_CHERRY_PICK_HELP > > > when using `git cherry-pick`, CHERRY_PICK_HEAD will be deleted, then > > > we will get an error when we try to use `git cherry-pick --continue` > > > or other cherr-pick command. > > > > I think that the GIT_CHERRY_PICK_HELP is an implemention detail for > > various forms of rebase to use cherry-pick as a backend and not for > > use by end users. > > > > But someone complain to me that the cherry-pick advice is not good enough. I agree it's not good enough. In my opinion `git cherry-pick` should be a more prominent command, and a lot functionality is missing. > Think about a git newbie is cherry-picking a patch series containing > several commits, > E.g. > > git cherry-pick dev~3..dev > > And then he (she) will see these advice info: > hint: after resolving the conflicts, mark the corrected paths > hint: with 'git add <paths>' or 'git rm <paths>' > hint: and commit the result with 'git commit' > > After he resolving git conflict, execute 'git commit' according to the > prompt, A terrible thing happened: CHERRY_PICK_HEAD is deleted > by git and no errors are output. But in fact .git/sequencer still exists, > Wait until he uses the cherry-pick command next time, the error appears: > > error: cherry-pick is already in progress > hint: try "git cherry-pick (--continue | --abort | --quit)" > fatal: cherry-pick failed > > So we should not encourage users to use git commit when git cherry-pick. > It would be great if it could provide advice similar to rebase, like this: > > Once you are satisfied with your changes, run > > git cherry-pick --continue Agreed. -- Felipe Contreras
