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. 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. See for example: http://thread.gmane.org/gmane.comp.version-control.git/15148/focus=15476 That is why I said: Of course, the user needs to understand what he or she is doing (see http://thread.gmane.org/gmane.comp.version-control.git/136166/focus=136171 for example). And that is one reason we (at least I) try to teach new people to start working from a clean tree, until they get comfortable working with mergy operations. and that is why the archived article referenced above refers to http://gitster.livejournal.com/29060.html You need to be able to tell the two ways in which a "mergy" operation can "fail" apart [*1*]. - One that stops before touching anything (either your index was dirty and nothing happened, or your index was clean but you had local modifications in your work tree). You do not run "git reset --merge", for this one; and - Another that goes ahead and results in conflicts. When you got these conflicts, you can "reset --merge" them away. [Footnote] *1* Strictly speaking, the latter is not even a "failure"; it allowed you to make progress, merging all the auto-mergeable parts without your help, and only asking you to handle the remainder. -- 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