On Wed, Feb 26, 2014 at 3:57 PM, Matthieu Moy <matthieu....@grenoble-inp.fr> wrote: > If you were to design "git reset"'s interface from scratch, your > proposal would make sense. But we're talking about a change, and you > can't expect that users never use the current behavior. At the very > least, there should be a warning telling the user that the behavior > changed, and I'm really afraid that the warning goes along the lines of > "I've thought you'd prefer me to discard your unsaved changes, please > rewrite them if you actually didn't want me to". > >>> I'm not really convinced that this is such a good change, and if we go >>> this way, there should be a transition to let users stop using >>> argumentless "git reset" to reset the index during a merge. >> >> Yeah, this breaks compatibility, but like I said, during a merge, I don't >> see a good reason to do "git reset --mixed", > > The point with backward compatibility is not to know whether users have > a good reason to, but whether you can guarantee that no one ever does > it.
Yeah, I do see what you mean. But the problem of using "git reset --mixed" during a merge is problematic too. It leaves you with a mix of merge changes and local changes. As Junio pointed out, new files will also be left in the worktree. So users would have to clean all that up manually. Perhaps what Junio suggested is a better approach. Slowly phase out this behavior by printing out warnings. Then eventually erroring out in this situation, and then finally switch to a new behavior, whatever that may be. 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
