Search code examples
gitmergeresetpull

Why do I sometimes see an "Entry 'filename' not uptodate. Cannot merge." after a 'git reset --hard' and a 'git pull'?

Occasionally, when I do the following...

git reset --hard
HEAD is now at 0123abde comment is here
git pull
Updating 0123abde..456789fa

I get the error...

error: Entry 'filename' not uptodate. Cannot merge.

The only workaround I have found is to 'git reset --hard', delete the offending file(s) then do 'git pull'. That doesn't seem right to me. Shouldn't a hard reset remove any and all local changes thus allowing me to pull the latest without any merge issues? Am I using git wrong? :)

This is on a CI machine so any changes here are unwanted. I'm using git version 1.6.1.9.g97c34 on Windows Vista.

Solution

  • The general idea behind "Entry 'filename' not uptodate. Cannot merge." is:

    You have changes to files in your working directory that will be overwritten, removed or otherwise lost if the checkout and change to the new branch were to proceed.

    It has been reported that this message could be "spurious" at time, (potentially because "git pull" did not refresh the index before trying to merge) but the fix was in Git1.6.1.
    However, it may still be in mSysGit 1.6.1, so do you see the same error with a more recent mSysGit version ? (like 1.6.3)

    Before Git 2.30.1 (Q1 2021), "git stash"(man) did not work well in a sparsely checked out working tree.

    See commit ba359fd, commit b34ab4a, commit a31e48d (01 Dec 2020) by Elijah Newren (newren).
    (Merged by Junio C Hamano -- gitster -- in commit 62fb47a, 15 Jan 2021)

    t7012: add a testcase demonstrating stash apply bugs in sparse checkouts

    Signed-off-by: Elijah Newren

    Applying stashes in sparse-checkouts, particularly when the patterns used to define the sparseness have changed between when the stash was created and when it is applied, has a number of bugs.

    The primary problem is that stashes are sometimes only partially applied.

    In most such cases, it does so silently without any warning or error being displayed and with 0 exit status.

    There are, however, a few cases when non-translated error messages are shown and the stash application aborts early.

    The first is when there are files present despite the SKIP_WORKTREE bit being set, in which case the error message shown is:

    error: Entry 'PATHNAME' not uptodate. Cannot merge.

    The other situation is when a stash contains new files to add to the working tree; in this case, the code aborts early but still has the stash partially applied, and shows the following error message:

    error: NEWFILE: does not exist and --remove not passed
fatal: Unable to process path NEWFILE