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

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 13, 2010, 06:55 UTC
Message-ID: <7vtyuqtrx4.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20100111041318.GA9806@progeny.tock>

Jonathan Nieder <jrnieder@gmail.com> writes:

Show 11 quoted lines

> | A merge is always between the current HEAD and one or more commits
> | (usually, branch head or tag), and the index file must match the tree of
> | HEAD commit (i.e. the contents of the last commit) when it starts out. In
> | other words, git diff --cached HEAD must report no changes. (One exception
> | is when the changed index entries are already in the same state that would
> | result from the merge anyway.)
>
> The potentially problematic scenario for "git reset --merge" is this
> last one, where a changed index entry is already in the same state
> that would result from the merge.  Would a "git reset --merge" reset
> the changed contents away?

It will discard the change, the one you independently picked up, but the change agreed with what was done by the the trash history that you are cancelling merge with. You wouldn't miss losing the same change as in that trash history.