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

From: Jeff King <peff@peff.net>
Date: Aug 25, 2021, 01:05 UTC
Message-ID: <YSWXSWiDWNU93lhC@coredump.intra.peff.net>
In-Reply-To: <01514401-78f6-3fdc-aa74-c519fb6ab427@rawbw.com>

On Tue, Aug 24, 2021 at 09:41:49AM -0700, Yuri wrote:

Show 24 quoted lines

> 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