Re: [RFC] sequencer: allow metadata to be saved if using cherry-pick --no-commit

[Edmundo Carmona Antoranz <eantoranz@gmail.com>]

On Wed, Oct 21, 2020 at 1:46 PM Junio C Hamano <gitster@pobox.com> 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.
>