The gitsm download method jumps through hoops (pretending it's a non-bare repo) to get the submodules fetched into the 'modules' directory relative to ud.clonedir, then the unpack() method ignores the modules directory entirely and lets `submodule update` re-clone the submodules from upstream in *do_unpack* rather than do_fetch. This behavior was introduced by "fetch2/gitsm: Fix when repository change submodules", prior to this commit the modules were being copied correctly. If the modules in the clone directory don't match the branch we need to check out, then the download method should be fixed to correctly update the modules directory, rather than ignoring it entirely. With the current behavior, it's not possible to build with a fully populated DL_DIR and no network connectivity available.
There was discussion about this on the bitbake list, seems there was a patch identified which caused this: http://lists.openembedded.org/pipermail/bitbake-devel/2017-July/008835.html
I think it's clear the specified commit should be reverted, but we don't want that to reintroduce the issue that commit was trying to fix, so we'll need to do some testing with that and potentially introduce a unit test or two to go along with the revert.
2 patches sent to the bitbake list for this.
Having rethought and tested the patches I submitted, there's just no viable way to work around this without reworking how gitsm works. Including submodules inside the git repo will *always* make assumptions about exactly what modules are included and from where, which can change not just between branches, but between srcrevs, and the repository and mirror tarball can be used for any number of those, so either we lock down both the repo and mirror tarball to srcrev, or we stop shipping submodules inside the git repository. Given this, the only viable path forward for this issue is Issue #11831. I'm keeping the issue open, as clearly this bug still exists, and will need verification.
The gitsm fetcher has been refactored over the last year. See the thud (1.40) and newer branches.