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

[Jonathan Nieder <jrnieder@gmail.com>]

Ramkumar Ramachandra wrote:

> To abort, perform a "rerere clear" and "reset --hard" to the ref
> specified by the HEAD file introduced earlier in the series.

The above doesn't explain why, so it makes it harder to answer:

>  Should I be
>  re-implementing "reset --hard" like this?

So I'll try to fill in the blanks.  Wouldn't it be better to call
"reset --merge" code?  That is what "git merge --abort" does.

Let's consider an example.

Suppose I have run "git cherry-pick foo" and run into a conflict.  Now
I start to fix things up the way I like, but I suddenly realize that
the cause was cherry-picking the wrong commit; it's better to start
over and do that.  So I try to abort.

I have some changes to files that did not participate in the automatic
cherry-pick:

 1. for unrelated reasons, I bumped the version number in the Makefile
 as a reminder not to forget later, without commiting it or marking
 with "git add";

 2. I (manually) moved a declaration to a different header file to
 reflect differences between the codebase at the time of foo^ and HEAD,
 to get it to compile.  Which works, so I mark it with "git add" for
 incorporation into the corrected cherry-pick commit.

With "git reset --merge", (1) is left alone, while (2) is backed out,
unmerged entries are of course clobbered, and hazy cases in which I
make some changes, "git add", and then make more changes without "git
add" cause the operation to error out.  It would be nicer if git could
read my mind, but at first glance this seems like an okay second-best.

Are there other considerations or situations that would lead to a
different conclusion?  (Not a rhetorical question.)

Hope that helps,
Jonathan