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

Ramkumar Ramachandra wrote:

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

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