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, 19:05 UTC
- Message-ID
- <YSaUcDQ+MIUdw6Ji@coredump.intra.peff.net>
- In-Reply-To
- <CABPp-BEMXW3EOdT4jt1g63uPyZ5YuKUPfBE9BL=E66QcT5uXXA@mail.gmail.com>
On Wed, Aug 25, 2021 at 08:42:09AM -0700, Elijah Newren wrote:
Show 20 quoted lines
> > 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