Re: [PATCH 12/14] revert: Introduce --reset to cleanup sequencer data

Ramkumar Ramachandra wrote:

quoted

--- a/t/t3507-cherry-pick-conflict.sh
+++ b/t/t3507-cherry-pick-conflict.sh

[...]

As you can see, there is no "reset --hard" in these

In this one, there's "git checkout -f && git read-tree -u --reset HEAD
&& git clean -fdx", which is almost the same thing.

quoted

--- a/t/t3505-cherry-pick-empty.sh
+++ b/t/t3505-cherry-pick-empty.sh

This one is not a typical script, I think --- if you knew the
cherry-pick was going to be empty, why did you try it in the first
place?  I think it would make sense to make it "git reset --hard" at
the beginning of each test as a separate, preparatory patch with
explanation.

[...]

There is however, one other thing I can do: if there is
nothing left to cherry-pick after a successful conflict resolution +
git commit, I can modify commit.c to blow away the sequencer state
after checking appropriately.  This will also have a nice end-user
experience side-effect:
$ git cherry-pick moo
fatal: Conflict in foo!
$ echo "Resolved" > foo
$ git add moo
$ git commit
$ git cherry-pick --continue # This no-op will be unnecessary

Though it's not obvious to me how this would affect the scripts above,
it sounds like a nice enhancement to me independently, fwiw.

Then again, teaching commit about the sequencer is inelegant,

It's possible to add some hook-like thing to do this, or to structure
the code as if a hook was used.

and it's
possible to achieve this effect in another way: when a conflict is
encountered in the sequencer && length(todo_file) == 1, throw away the
sequencer state.

Yep, that seems like basically the same effect.  Are there downsides?
(Maybe years from now when a "git cherry-pick --rewind" is introduced
we would regret this?  But that can be figured out years from now.)