Thread (8 messages) flat view 8 messages, 2 authors, 2016-06-15

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help