Sverre Rabbelier wrote:
quoted text
> On Fri, Oct 22, 2010 at 10:12, Johan Herland <johan@herland.net> wrote:

quoted text
>> Yes, that makes sense to me, especially if we make a 'git merge --abort'
>> synonym. Alternatively, we can make 'git merge --abort' check for
>> MERGE_HEAD, and then defer to 'git reset --merge', while leaving 'git
>> reset --merge' as-is.
>
> ACK to that. I think people using 'git reset --merge' know what
> they're doing, and should be able to clobber their changes (viz. `git
> reset --hard`),

Wait a second: isn't that exactly what 'git reset --hard' is for?

I doubt[*] 'git reset --merge' could be anything but a mistake when used
outside the context of a merge (remember that the plumbing is called
"read-tree", not "reset").

[*] This is disingenuous of me.  I used to use "git reset --merge <commit>"
with the intent of "git reset --keep <commit>", since the latter did
not exist yet.  But I was wrong. :)

Here's a start for the interested:

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
diff --git a/builtin/reset.c b/builtin/reset.c
index 0037be4..a4fc7b3 100644
--- a/builtin/reset.c
+++ b/builtin/reset.c
@@ -335,6 +335,9 @@ int cmd_reset(int argc, const char **argv, const char *prefix)
 		die("%s reset is not allowed in a bare repository",
 		    reset_type_names[reset_type]);
 
+	if (reset_type == MERGE && !file_exists(git_path("MERGE_HEAD")))
+		die("You are not in the middle of a merge (MERGE_HEAD does not exist).");
+
 	/* Soft reset does not touch the index file nor the working tree
 	 * at all, but requires them in a good order.  Other resets reset
 	 * the index file to the tree object we are switching to. */
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html