I'm seeing an issue when doing a recursive checkout of submodules in our repository where the Git plugin will attempt to check out a non-existent submodule that was recently added in a different branch but has not yet been merged. This is causing all subsequent builds to fail that have not yet had a merge to include this submodule. Here is an excerpt from our build logs:

I've blanked out sensitive path information with ***, just an FYI:
11:19:09 Checking out Revision *** (origin/master)
11:19:09 > git config core.sparsecheckout # timeout=10
11:19:09 > git checkout -f ***
11:19:10 > git rev-list *** # timeout=10

11:19:10 > git remote # timeout=10
11:19:10 > git submodule init # timeout=10

11:19:12 > git submodule sync # timeout=10

11:19:18 > git config --get remote.origin.url # timeout=10

11:19:18 > git config --get-regexp ^submodule # timeout=10
11:19:19 > git config --get submodule.BuildFiles/***.url # timeout=10
11:19:19 > git submodule update --init --recursive BuildFiles/***

11:19:23 > git config --get submodule.***.url # timeout=10
11:19:23 > git submodule update --init --recursive ***

11:19:27 > git config --get submodule.test/***.url # timeout=10

11:19:27 > git submodule update --init --recursive test/***

11:19:29 FATAL: Command "git submodule update --init --recursive test/***" returned status code 1:
11:19:29 stdout:
11:19:29 stderr: error: pathspec 'test/***' did not match any file(s) known to git.
11:19:29
11:19:29 hudson.plugins.git.GitException: Command "git submodule update --init --recursive test/**" returned status code 1:
11:19:29 stdout:
11:19:29 stderr: error: pathspec 'test/***' did not match any file(s) known to git.

I've traced the issue to the command "git config --get-regexp ^submodule". This is picking up the offending submodule and including it in the recursive update, despite it not being attached to the commit in question. This seems to be a problem with the Git program itself but when I do a recursive update from the command line, I don't see this issue. It seems to be attached to the process through which the Jenkins Git plugin identifies the submodules present. Would it be possible to add a check so the update does not include submodules that don't exist in the commit being targeted? I assume this will be resolved once the submodule gets merged into master but it's very inconvenient for the time being as all our follow-up builds are now failing.

I'm not sure if this is relevant but the current branch setup has it pointed to a detached head on a specific commit. This could be impacting how the submodules are being picked up and returned.

Thanks!