Jonathan Nieder <jrnieder@xxxxxxxxx> writes: > | 1. Even if you may have local modifications in your working tree, you > | can safely say "git pull" when you know that the change in the other > | branch does not overlap with them. > | 2. After inspecting the result of the merge, you may find that the > | change in the other branch is unsatisfactory. Running "git reset > | --hard ORIG_HEAD" will let you go back to where you were, but it will > | discard your local changes, which you do not want. "git reset --merge" > | keeps your local changes. > >> while possible, it leaves you in a state that is hard to >> +back out of in the case of a conflict. >> + > > 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. 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. -- 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