Hi Jonathan, Jonathan Nieder writes: > The documentation could say: > > Â Â Â ÂTo wipe out everything and get back to where you started, use: > > Â Â Â Â Â Â Â Âgit reset --hard PRE_CHERRY_PICK_HEAD 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. Hm, you're suggesting using a ref -- I was wondering what to do with CHERY_PICK_HEAD. I'm not entirely convinced, but I'll wait for the others to comment and think about this for some time. > What if instead of --abort something else were simpler to think about? > As a random example, I can imagine a "git sequencer --edit" command > that would present the sequence in an editor and let me revise the > plan --- would that do the trick? > > Â Â Â Â1 > Â Â Â Â2 > Â Â Â Â3 > Â Â Â Â4 > Â Â Â Â* YOU ARE HERE > Â Â Â Â5 > Â Â Â Â6 > Â Â Â Â7 > Â Â Â Â8 > > Â- Remove lines 5-8: removes sequencer state, leaves HEAD as is > Â- Remove everything: rewinds to abort sequence > Â- Add a line 2.5 between 2 and 3: rewind to 2, cherry-pick 2.5, > Â continue. Interesting perspective. I essentially have to keep two TODO files and run a diff until I find the first different line. Then, I have to reset to that SHA-1 and replay the rest of the user-edited TODO. Can be complicated to get right, but it seems like quite an elegant interactive solution. It takes care of all three: --abort and --skip. We'd still need a --continue to non-interactively continue after a conflict resolution though, no? > Which is to say: if you have a story about what --abort will be used > for, the life of others evaluating the thing becomes better and the > upsides and downsides can be seen in perspective. ÂA story like "am > and rebase have --abort, so cherry-pick should have one, too" is > harder to think about. I agree. There's little point in being stuck with historical conventions -- we should try something new and see how it works out :) Thanks. -- Ram -- 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