Re: [RFC 3/3] reset: Change the default behavior to use "--merge" during a merge

[Andrew Wong <andrew.kw.w@gmail.com>]

On Wed, Feb 26, 2014 at 3:48 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> I really don't like the idea of making "git reset" modal, though.  I'd
> rather that reset --mixed print some advice about how to recover from
> the mistake, which would also have the advantage of allowing scripts
> that for whatever reason used "git reset" in this situation to
> continue to work.

In the case where user had unstaged changes before running "git
merge", there's no way to recover from the mistake. Their worktree is
left with a mix of both the merge changes and their original unstaged
changes. As Junio pointed out, new files will also be left in the
worktree, so the next attempt to "git merge" will fail until the files
are removed. There's no way to recover from it except to have the user
manually clean out the merge changes and new files manually. That's
why "git reset --mixed" doesn't seem sensible during a merge.

That said, I do feel it might not be a good idea to have the default
behavior of "git reset" change depending on the context. What Junio
suggested might be a better approach. To have "git reset" error out
instead may be a better alternative, since that doesn't silently do
something else and break compatibility.

Andrew