Junio C Hamano <gitster@xxxxxxxxx> 于2021年8月15日周日 上午4:33写道： > > "ZheNing Hu via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > > > From: ZheNing Hu <adlternative@xxxxxxxxx> > > > > In the past, git cherry-pick would print such advice when > > there was a conflict: > > 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' > > In our log messages, we desciribe the current state in the present > tense. > > It may be worth mentioning that this is because the program > originally was about picking only one commit and the hint was > inherited from those days. Or it may not. I dunno. > Yes, may look at the time, the design is correct. > > But in fact, when we want to cherry-pick multiple commits, > > we should not use "git commit" after resolving conflicts, which > > will make Git generate some errors. We should recommend users to > > use `git cherry-pick --continue`, `git cherry-pick --abort`, just > > like git rebase does. > > I am not sure "should not" is the right phrase. Also it does not > help readers to have a vague "generate some errors" than not saying > anything---it leaves readers puzzled with "what errors???" > yes, this error is specifically that if we want pick a series of commits, after resolving conflicts and use git commit, `.git/sequencer` still exists, but git cherry-pick has ended (the next step cherry-pick is not performed). This may be a very strange critical state. > Whether picking a single commit or a series of commits, after > resolving conflicts in the current step, wouldn't > > $ git commit ;# to conclude the resolution > $ git cherry-pick --continue > > do the right thing? > I think you mean that git commit is used to end a single cherry-pick. But in the face of a series of commits, errors will occur. > > This is the improved advice: > > It may be an improved advice, but just omit it and say something > like: > > Suggest use of "git cherry-pick --contiue", so that it would > also apply to cases where multiple commits are being picked. > > The actual message does not have to be reproduced here, as it is in > the source, and it can be seen in the test ;-) > Yes, maybe the commit message should be shorter and more concise. > That would make the proposed log message conform to our norm, > i.e. brief description of what happens with the current system, > followed by description of the perceived problem, followed by > an order to the codebase to become different in a specific way > that solves the problem. > > Taken together, perhaps > > "git cherry-pick", upon seeing a conflict, says: > > hint: ... > > as if running "git commit" to conclude the resolution of > this single step were the end of the story. This stems from > the fact that the command originally was to pick a single > commit and not a range of commits, and the message was > written back then and has not been adjusted. > > When picking a range of commits and the command stops with a > conflict in the middle of the range, however, after > resolving the conflict and (optionally) recording the result > with "git commit", the user has to run "git cherry-pick > --continue" to have the rest of the range dealt with, > "--skip" to drop the current commit, or "--abort" to discard > the series. > Ok, I understand now, git commit just stopped git cherry-pick by delete CHERRY_PICK_HEAD in sequencer_post_commit_cleanup(). we can still resume the process with git cherry-pick --continue. > Suggest use of "git cherry-pick --continue/--skip/--abort" > so that the message also covers the case where a range of > commits are being picked. > > > > Helped-by: Phillip Wood <phillip.wood@xxxxxxxxxxxxx> > > Hepled-by: Junio C Hamano <gitster@xxxxxxxxx> > > It seems that unlike other people I keep hepling you, whatever that > verb means ;-). > Ehhh, I seem to have forgotten the correction here. > Thanks. > Thanks. -- ZheNing Hu
