Junio C Hamano wrote: > Jonathan Nieder <jrnieder@xxxxxxxxx> writes: >> Oh, that is a problem. Maybe 'git merge' should refuse to merge >> unless told otherwise, if there is a dirty index and there might be >> conflicts. > > "git reset --merge" will keep your local changes after such a merge, and > "mergy" operations (not just "merge" but also "revert", "am -3", etc) > won't get you into a situation where you cannot, by refusing to do > anything when e.g. your index is dirty. Especially when Christian's > "reset --merge" update becomes solid, "... is hard to back out of" will > become a false statement. 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. As luck would have it, the remote version of main.c is exactly the same as my modified version, so the merge happily proceeds. Some other files merge cleanly. Eventually there is some conflict. Now I regret the pull. Will ‘reset --merge’ restore the index and work tree to its original state? If the change to main.c was _not_ staged, then the merge would have failed early, so that is not something to worry about. > 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). Agreed. And probably the user who understands what is going on will not make the mistake I described above. Otherwise, they could succumb to a related problem: Suppose all is as above, except that git detects no conflict. Suppose further that some upstream commit was bogus. Now I regret the pull. How can I restore the index and work tree to its original state? If I reset --hard (or --merge) to the previous HEAD commit, the modification to main.c is forgotten. In practice, I would do 'git reset --hard HEAD^ && git checkout HEAD@{1} -- main.c'. -- 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