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

> Elijah Newren <newren@gmail.com> 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.