Ramkumar Ramachandra wrote: > My notion of --abort has changed: I simply want to remove the state > files for the cherry-pick so that the user can execute more > cherry-pick/ revert commands. I didn't think a soft reset would be > intrusive. Well, if you understand this part then you can forget most of the rest of what I said. Think about this for a second. New user (or forgetful, experienced user), has just run git cherry-pick HEAD..topic to integrate the changes from topic in a linear history. Ran into conflicts, wanted to give up. Ran git cherry-pick --abort Would this person expect: - that "git diff --cached" would return a pile of changes - that "git reset --keep", "git reset --merge", "git checkout", "git merge", and various other commands would refuse to do much, for fear of clobbering the new "local changes" - that the worktree would be unchanged - etc Would they be happy about it? Just put yourself in their shoes. A soft reset is near the most intrusive behavior possible. And that is a good way to think about the UI for any new facility. If you disregard about how flexible it is in abstract, how easy to implement, how elegant-sounding and just think about a person using it will find her quality of life improved or worsened, that is (1) a good sanity-check on a design and (2) basically the only way to explain it to other people. -- 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