Spotted this when our Jenkins executors had git updated, and later managed to reproduce locally. The issue happens when fetching an updated ref from a remote, and that ref updates a submodule which is not checked out but whose folder is dirty. Steps to reproduce (on *nix) with repositories on GitHub: Scenario: git-fetch-bug repository with 2 branches, the HEADs for these branches point respectively to 2 different commits in a submodule. $ mkdir git_repo $ cd git_repo # Manually fetch "master" branch $ git init $ git remote add origin https://github.com/paolope/git-fetch-bug.git $ git fetch origin master # Checkout $ git checkout master # Repo now contains a folder named "sm" which is bound to contain a submodule checkout. But the submodule is not checked out yet. # Dirty that folder: $ touch sm/test # Fetching another branch will fail $ git fetch origin branch_1 Output: remote: Enumerating objects: 7, done. remote: Counting objects: 100% (7/7), done. remote: Compressing objects: 100% (3/3), done. remote: Total 5 (delta 2), reused 5 (delta 2), pack-reused 0 Unpacking objects: 100% (5/5), done. From https://github.com/paolope/git-fetch-bug * branch branch_1 -> FETCH_HEAD * [new branch] branch_1 -> origin/branch_1 Could not access submodule 'sm' # fails, plus no newline here :P! # Re-issuing the command succeeds $ git fetch origin branch_1 Output: From https://github.com/paolope/git-fetch-bug * branch branch_1 -> FETCH_HEAD I'd expect the command not to fail, or to fail consistently. This behaviour didn't happen in git 2.18.1, so the regression was introduced somewhere in between. It is possible that this is related to this issue: https://marc.info/?l=git&m=155246493613592&w=2 Regards, Paolo Pettinato **
