On Wed, Feb 26, 2014 at 3:48 PM, Jonathan Nieder <jrnie...@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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
