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

[Jeff King <peff@peff.net>]

On Wed, Aug 25, 2021 at 08:42:09AM -0700, Elijah Newren wrote:

> > Is it possible to give us a more complete example, including:
> >
> >   - a url for the repository
> >   - the commit at HEAD when you ran "git checkout"
> >   - the {hash} commit from which you rescued the files
> >   - the state of the remote branch (i.e., what we attempted to merge
> >     with "git pull")
> >
> > ?
> 
> The `git checkout {hash}~1 -- math/polymake` is enough to highlight
> that Yuri doesn't just have local changes (which the merge machinery
> should 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.
> """

Doh, you're right. I did a simple reproduction test, but in my example,
the merge was a fast-forward, which we do allow. Picking a branch more
carefully using:

  git for-each-ref --no-contains HEAD --no-merged HEAD refs/remotes/origin

shows the error. Sorry for the confusion.

-Peff