Andrew Wong <andrew.kw.w@xxxxxxxxx> writes: > If the user wants to do "git reset" during a merge, the user most likely > wants to do a "git reset --merge". This is especially true during a > merge conflict and the user had local changes, because "git reset" would > leave the merged changes mixed in with the local changes. This makes > "git reset" a little more user-friendly during a merge. But this breaks backward compatibility. I sometimes run "git reset" during a merge to only reset the index and then examine the changes introduced by the merge. With your changes, someone doing so would abort the merge and discard the merge resolution. I very rarely do this, but even rarely, I wouldn't like Git to start droping data silently for me ;-). 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. The other 2 patches look good to me. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html