CentOS Question posted in
The official documentation can be found here.

Git sparse checkout error "Entry 'path/to/file' not update. Cannot update sparse checkout" – CentOS

I’ve just done a sparse checkout following the steps below

git clone http://location/repo.git
# create .git/info/sparse-checkout file
git config --bool core.sparsecheckout true
git read-tree -mu HEAD

Unfortunately the final step fails with the error message

Entry 'path/to/file' not update. Cannot update sparse checkout

Which is strange because (1) path/to/file exists (2) the sparse checkout process succeeded on another machine git version 1.7.1 (Centos 6). The current machine is a Centos 7 box with git version 1.8.3.1 installed. The output of git config --list is identical on both machines.

Tags:

3

Answers


  1. Chosen as BEST ANSWER
    0

    I fixed the problem essentially by removing all the files and repeating the same steps. It has been suggested that this could be a bug in git, or IMO some sort of file corruption.

    Another solution that worked for me (YMMV). Try repeatedly checking out and the problematic directory and running git read-tree

    1. git checkout -- path/
    2. git read-tree -mu HEAD

  2. 0

    The error occurs (for files that are in the work-tree) if function ie_match_stat fails to match the stat info. This particular call to ie_match_stat passes CE_MATCH_IGNORE_VALID|CE_MATCH_IGNORE_SKIP_WORKTREE as ie_match_stat would normally obey the cache entry flags CE_VALID or CE_SKIP_WORKTREE by saying: the work-tree copy is up to date even if it’s not. The sparse checkout code uses the skip-worktree flag (CE_SKIP_WORKTREE) to mark files that should not be checked out, so that the rest of Git won’t complain about them being missing.

    Hence, the oddities here are:

    • The skip-worktree bit is set on a file that is in the work-tree. Why?
    • The index entry’s cached stat data for the this file do not match the lstat results from this file. Why?

    The answer to the first question could be: because a user set it (using git update-index). The answer to the second could be: because a user modified the file. So they’re not particularly odd at all, they just imply that the file does not match whatever was created by an initial checkout or git read-tree operation. If you don’t care about losing the contents of the file, feel free to remove it. If you do care about the contents, clear the skip-worktree bit (git update-index --no-skip-worktree), after which git diff should show what’s different.

    There may well be some bugs in this area, especially in Git versions that are this ancient (Git 1.8.x—current Git is 2.22).

    Login or Signup to reply.
  3. 0

    First, with Git 2.27 (Q2 2020), once you have remove the files, you can use git sparse-checkout reapply

    Second, the error message has changed (still with Git 2.27+):

    See commit 5644ca2, commit 681c637, commit ebb568b, commit 22ab0b3, commit 6271d77, commit 1ac83f4, commit cd002c1, commit 4ee5d50, commit f56f31a, commit 7af7a25, commit 30e89c1, commit 3cc7c50, commit b0a5a12, commit 72064ee, commit fa0bde4, commit d61633a, commit d7dc1e1, commit 031ba55 (27 Mar 2020) by Elijah Newren (newren).
    (Merged by Junio C Hamano — gitster — in commit 48eee46, 29 Apr 2020)

    unpack-trees: make sparse path messages sound like warnings

    Reviewed-by: Derrick Stolee
    Signed-off-by: Elijah Newren

    The messages for problems with sparse paths are phrased as errors that cause the operation to abort, even though we are not making the operation abort.

    Reword the messages to make sense in their new context.

    This is no longer:

    Cannot update sparse checkout

    But:

    The following paths are not up to date
    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search