From: Jonathan Nieder <jrnieder@gmail.com>
Date: Mon, 11 Jan 2010 04:13:18 GMT
Subject: Re: [PATCH v2 2/4] Documentation: warn prominently against merging with dirty trees
Message-ID: <20100111041318.GA9806@progeny.tock>
In-Reply-To: <7vzl4lbcfl.fsf@alter.siamese.dyndns.org>

Junio C Hamano wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:

>> Here is a scenario I worry about:
>>
>> Suppose I have a change to main.c staged, to add a feature that others
>> have discussed as well.  After a short distraction, I return and run
>> ‘git pull’ to see what upstream has been working on.
>
> If your index is dirty, any "mergy" operation will refuse to work *before*
> touching anything, so you won't use "git reset --merge" to begin with.

Yes, that is true.  And I was not worried about that.

As the git-merge manual explains:

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

> You are allowed to have local modifications only in your work tree.
> Furthermore, even git experts limit them to something they feel they can
> afford to lose and recreate easily if necessary.

Sadly, even a small change disappearing can be unnerving for an expert
and dangerous for a novice.

> You need to be able to tell the two ways in which a "mergy" operation can
> "fail" apart [*1*].

Thanks for bringing this up.  The manual does not emphasize that
point at all, but it should.

Jonathan