Re: [RFC PATCH v2] revert: Implement --abort processing

Ramkumar Ramachandra wrote:

Frankly, I'm still trying to understand how other people work -- I
don't use the porcelain much, and I dislike anything but the most
minimalistic automation.  I didn't even like the change to cherry-pick
where you can simply "git commit" after resolving a conflict; I still
prefer and use the more explicit "git commit -c" after removing the
CHERRY_PICK_HEAD.  Also, I *always* use rebase with --onto

I don't think that should stop you from thinking about how new
facilities help or interfere with work at all.  You use magit, right?
It automates all kinds of things.  And while each person is going to
use tools in different ways, that hasn't kept people from getting
things done in the past.

If you are thinking "I would never use 'git cherry-pick --abort' --- I
would just look in the reflog for a commit to 'reset --hard' to", then
you are *done*.  Just document it, make sure the reflog has useful
content to help out, and wait until someone complains and adds a
shortcut they like.

Addendum:  Personally I was happy about "git commit" that implicitly
takes the commit message from CHERRY_PICK_HEAD because it adds a

	Conflicts:

		Makefile

that I can use as a template for a message about the nature of the
conflict and how I fixed it up.  As a side note, I'm curious about
why you end up needing to remove the CHERRY_PICK_HEAD.  Is "git commit
-c interesting-patch" misbehaving somehow?  (It should ignore the
CHERRY_PICK_HEAD entirely.)