Git fetch bug in git 2.21+ "Could not access submodule '%s'"

["Paolo Pettinato (ppettina)" <ppettina@cisco.com>]

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
**