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

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 10, 2010, 06:31 UTC
Message-ID: <7vskaefp2v.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20100110044949.GA8974@progeny.tock>

Jonathan Nieder <jrnieder@gmail.com> writes:

Show 16 quoted lines

> |     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.