On Wed, Feb 26, 2014 at 1:21 PM, Matthieu Moy <matthieu....@grenoble-inp.fr> wrote: > 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 don't think it's actually dropping data though, because your changes just come from "git merge". So you can also do the merge again. To examine the changes, you're saying you'd do "git reset && git diff". But without doing "git reset", couldn't you do "git diff HEAD" to get the diff? This also has the advantage of keeping git in the merging state, so you can decide to continue/abort the merge later on. > 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", and not "git reset --merge". Especially when there are local changes, "--mixed" would actually cause more headaches than "git reset --merge", because you would lose the distinction between merge changes and unstaged changes. 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
