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 Tue, Aug 24, 2021 at 09:41:49AM -0700, Yuri wrote:

> In the FreeBSD ports repository I resurrected the directory (that was
> removed a long time ago) with the command:
> 
> > $ git checkout {hash}~1 -- math/polymake
> 
> 
> I made local changes to this directory and called 'git add math/polymake'.
> 
> Then 'git pull' complained:
> 
> > $ git pull
> > error: Your local changes to the following files would be overwritten by
> merge:
> >   math/polymake/Makefile math/polymake/distinfo
> math/polymake/files/patch-Makefile
> math/polymake/files/patch-support_install.pl math/polymake/pkg-descr
> math/polymake/pkg-plist
> 
> 
> No incoming changes affect math/polymake. Nobody has created this directory
> simultaneously with me. There is no intersection with incoming changes.
> 
> 
> Why does 'git pull' complain then?

It's hard to say without seeing a full example. The merge machinery is
supposed to handle this situation (and indeed, in a simple reproduction
example it does). So presumably it thinks the other side may have
touched those files for some reason. Perhaps it's confused by rename
detection?

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

?

-Peff