Re: [PATCH 4/7] revert: allow single-pick in the middle of cherry-pick sequence

[Ramkumar Ramachandra <artagnon@gmail.com>]

Hi,

Jonathan Nieder wrote:
> When I messed up a difficult conflict in the middle of a cherry-pick
> sequence, it can be useful to be able to 'git checkout HEAD . && git
> cherry-pick that-one-commit' to restart the conflict resolution.

I was about to complain about the commit message until I noticed that
Junio already fixed it in `next`:

    revert: allow single-pick in the middle of cherry-pick sequence

    After messing up a difficult conflict resolution in the middle of a
    cherry-pick sequence, it can be useful to be able to

        git checkout HEAD . && git cherry-pick that-one-commit

    to restart the conflict resolution. The current code however errors out
    saying that another cherry-pick is already in progress.

Interesting concept; let's see how it's implemented.

> Suggested-by: Johannes Sixt <j6t@kdbg.org>

Could you link to the corresponding thread with Johannes?

> diff --git a/builtin/revert.c b/builtin/revert.c
> index 71570357..dcb69904 100644
> --- a/builtin/revert.c
> +++ b/builtin/revert.c
> @@ -1072,6 +1072,12 @@ static int sequencer_continue(struct replay_opts *opts)
>        return pick_commits(todo_list, opts);
>  }
>
> +static int single_pick(struct commit *cmit, struct replay_opts *opts)
> +{
> +       setenv(GIT_REFLOG_ACTION, action_name(opts), 0);
> +       return do_pick_commit(cmit, opts);
> +}

single_pick as opposed to the continue_single_pick introduced in 2/7.

>  static int pick_revisions(struct replay_opts *opts)
>  {
>        struct commit_list *todo_list = NULL;
> @@ -1097,6 +1103,26 @@ static int pick_revisions(struct replay_opts *opts)
>                return sequencer_continue(opts);
>
>        /*
> +        * If we were called as "git cherry-pick <commit>", just
> +        * cherry-pick/revert it, set CHERRY_PICK_HEAD /
> +        * REVERT_HEAD, and don't touch the sequencer state.
> +        * This means it is possible to cherry-pick in the middle
> +        * of a cherry-pick sequence.
> +        */

Conceptually all very good.  What I'm really interested in seeing is
how you persist opts for "cherry-pick --continue" when a single-commit
pick fails: in other words, how you manage to get " --continue of
single-pick respects -x" to pass.

> +       if (opts->revs->cmdline.nr == 1 &&
> +           opts->revs->cmdline.rev->whence == REV_CMD_REV &&
> +           opts->revs->no_walk &&
> +           !opts->revs->cmdline.rev->flags) {

Yuck, seriously.
1. I'd have expected you to check opts->revs->commits, not
opts->revs->cmdline.nr.  Okay, you're using the cmdline because the
revision walk hasn't happened yet.
2. Why are you using opts->revs->cmdline.rev->whence as opposed to
opts->action?  Why do you want to expose the underlying revision
walking mechanism?
3. When will the opts->revs->no_walk condition not be satisfied?  Only
when you explicitly set it to 0 or NULL, right -- where is this
happening in revert.c?
4. Why are you checking flags?  When is this condition not going to be
satisfied?

Since 3 and 4 indicate that you're being overly defensive, consistency
requires you to guarantee that this code will work no matter what the
rev_info struct is filled up with prior to this segment.
Is this true?

> +               struct commit *cmit;
> +               if (prepare_revision_walk(opts->revs))
> +                       die(_("revision walk setup failed"));
> +               cmit = get_revision(opts->revs);
> +               if (!cmit || get_revision(opts->revs))
> +                       die("BUG: expected exactly one commit from walk");
> +               return single_pick(cmit, opts);
> +       }

I'd have expected you to reuse prepare_revs().

> +       /*
>         * Start a new cherry-pick/ revert sequence; but
>         * first, make sure that an existing one isn't in
>         * progress

Since all your new code is a special case of "Start a new cherry-pick/
revert sequence", you don't check the sequencer state in the first
place.

> diff --git a/t/t3510-cherry-pick-sequence.sh b/t/t3510-cherry-pick-sequence.sh
> index 56c95ec1..98a27a23 100755
> --- a/t/t3510-cherry-pick-sequence.sh
> +++ b/t/t3510-cherry-pick-sequence.sh
> @@ -50,6 +50,18 @@ test_expect_success 'cherry-pick persists data on failure' '
>        test_path_is_file .git/sequencer/opts
>  '
>
> +test_expect_success 'cherry-pick mid-cherry-pick-sequence' '
> +       pristine_detach initial &&
> +       test_must_fail git cherry-pick base..anotherpick &&
> +       test_cmp_rev picked CHERRY_PICK_HEAD &&
> +       # "oops, I forgot that these patches rely on the change from base"
> +       git checkout HEAD foo &&
> +       git cherry-pick base &&
> +       git cherry-pick picked &&
> +       git cherry-pick --continue &&
> +       git diff --exit-code anotherpick
> +'

Cute feature, although I don't ever recall needing it personally.  Why
does this relatively esoteric "feature" belong along with the other
"maintenance patches" in  jn/maint-sequencer-fixes?

-- Ram