Re: [RFC PATCH v2] revert: Implement --abort processing
From: Ramkumar Ramachandra <hidden>
Date: 2016-06-15 22:51:28
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