Re: [PATCH v2 2/4] Documentation: warn prominently against merging with dirty trees

Jonathan Nieder [off-list ref] 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.

quoted

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.