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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html