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

[Junio C Hamano <gitster@pobox.com>]

Jonathan Nieder <jrnieder@gmail.com> 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.