Re: git merge --abort? [was: Re: [PATCHv4 00/21] git notes merge]
- From
Jonathan Nieder <jrnieder@gmail.com>
- Date
- Oct 22, 2010, 15:48 UTC
- Message-ID
- <20101022154815.GE9224@burratino>
- In-Reply-To
- <AANLkTimzryq2Qa5sZNmXVY5Z1epg5Zxe3TMk9CX_+VX8@mail.gmail.com>
Sverre Rabbelier wrote:
> On Fri, Oct 22, 2010 at 10:12, Johan Herland <johan@herland.net> wrote:
Show 8 quoted lines
>> 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. */