Ramkumar Ramachandra wrote: >> --- 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. >> --- 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.) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html