On Wed, Oct 21, 2020 at 1:46 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > So, personally, I am fairly negative on this line of change. If the > user says upfront "--no-commit", then user does not want a commit, > so why should we even allow "--continue"? This is the way merge --no-commit works, actually. You run --no-commit, then you run merge --continue to wrap it up and that's why to me it had always felt a bit off in terms of consistency of the UI. > > Before dismissing the idea totally, let's see what potential use > cases this change _could_ benefit, and see if there are already ways > to satisfy these use cases without making this change. For example, > if the user wants to examine the result before actually "committing" > to move the target branch forward with this change, keeping it an > option to back out if the result of cherry-picking turns out to be > bad, the "--no-commit first, examine, and --continue or --abort" > sequence may help such a workflow. Case in point, I am working on a script that corrects EOL format of files in a branch. When I started developing it, I was trusting that I could run cherry-pick --no-commit so that I could then check the exit code of git to see if there had been problems or not in the operation. If there were, I would correct the EOL format of the files. Then, successful cherry-pick or not, I would run cherry-pick --no-commit and it would work.... but that was when I realized that cherry-pick --no-commit is not keeping the information. Given that --no-commit _forgets_ the information from the revision, I have to run a normal cherry-pick. If it fails, I correct the EOL format and then I run cherry-pick --continue. It is noty like a game changer, you know... I can live with it.... how many people have complained about it, anyway? I just find it inconsistent in terms of how cherry-pick/merge --no-commit behave. https://github.com/eantoranz/conflict_book/blob/0385d240dda962512b215781039ed42ec2f12ec2/scripts/correct_eol.sh#L197 Anyway, thanks for all your feedback and let's see if there are more comments. BR > > But the user can already do so without this change: > > $ git checkout target_branch^0 ;#detach > $ git cherry-pick source_branch > ... examine the result ... > ... and if it is satisfactory ... > $ git checkout -B target_branch > ... or if it is not, then discard ... > $ git checkout target_branch > > > With this patch, we allow sequencer to save the metadata from the original > > cherry-pick operation so that 'git cherry-pick --continue' can be called. >
