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

From: Edmundo Carmona Antoranz <eantoranz@gmail.com>
Date: Oct 21, 2020, 20:45 UTC
Message-ID: <CAOc6etbSbg0rDrqu__MASTEdz2FhnhxtQLn6gvhBZL8BLz+AQQ@mail.gmail.com>
In-Reply-To: <xmqqv9f37476.fsf@gitster.c.googlers.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.

Show 9 quoted lines

>
> 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

Show 14 quoted lines

>
> 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.
>