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

Junio C Hamano wrote:

Jonathan Nieder [off-list ref] writes:

quoted

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