Re: [PATCH 4/7] revert: allow single-pick in the middle of cherry-pick sequence
From: Ramkumar Ramachandra <hidden>
Date: 2016-06-15 22:52:38
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 <redacted>
Could you link to the corresponding thread with Johannes?
quoted hunk ↗ jump to hunk
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.
quoted hunk ↗ jump to hunk
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.
quoted hunk ↗ jump to hunk
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