Junio C Hamano wrote: > Jonathan Nieder <jrnieder@xxxxxxxxx> writes: >> Here is a scenario I worry about: >> >> Suppose I have a change to main.c staged, to add a feature that others >> have discussed as well. After a short distraction, I return and run >> ‘git pull’ to see what upstream has been working on. > > If your index is dirty, any "mergy" operation will refuse to work *before* > touching anything, so you won't use "git reset --merge" to begin with. Yes, that is true. And I was not worried about that. As the git-merge manual explains: | A merge is always between the current HEAD and one or more commits | (usually, branch head or tag), and the index file must match the tree of | HEAD commit (i.e. the contents of the last commit) when it starts out. In | other words, git diff --cached HEAD must report no changes. (One exception | is when the changed index entries are already in the same state that would | result from the merge anyway.) The potentially problematic scenario for "git reset --merge" is this last one, where a changed index entry is already in the same state that would result from the merge. Would a "git reset --merge" reset the changed contents away? > You are allowed to have local modifications only in your work tree. > Furthermore, even git experts limit them to something they feel they can > afford to lose and recreate easily if necessary. Sadly, even a small change disappearing can be unnerving for an expert and dangerous for a novice. > You need to be able to tell the two ways in which a "mergy" operation can > "fail" apart [*1*]. Thanks for bringing this up. The manual does not emphasize that point at all, but it should. Jonathan -- 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