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

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Jan 11, 2010, 04:13 UTC
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:

Show 8 quoted lines

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