Re: 'git pull' complains that a locally resurrected directory would be overwritten by merge when no pulled changes are affecting that directory

Elijah Newren [off-list ref] writes:

... allow if the incoming changes don't touch the same files), but
local *staged* changes.  As per the merge manpage:

"""
To avoid recording unrelated changes in the merge commit, git pull and
git merge will also abort if there are any changes registered in the
index relative to the HEAD commit.
"""

While this particular example could theoretically be handled by the
merge machinery without requiring the index match HEAD,...

While I do not mind seeing a patch that loosens the condition ONLY
when the merge will cleanly auto-resolve without end-user
interaction, when any paths conflict and require editing by the
end-user, it is pretty much essential to require that the index
matches HEAD to keep "git merge" usable. 

This is because the final step to conclude such an "automated
procedure cannot cleanly resolve, so the end user helps resolving
with the editor and mark the resolved paths with 'git add' or 'git
rm'" session will become very error prone if we did not have the
requirement.  Not just the user MUST remember not to use "commit -a"
or "git add" a path that was already dirty in the working tree
before the merge started (which is the consequence of the current
requirement, which allows local changes to the unrelated working
tree files), they must MUST remember to somehow EXCLUDE the changes
already registered for unrelted paths from the concluded merge.