Thank you for your feedback and thanks for noticing that I missed the Signed-off. The answer to your question about why I just not simply extend the already existing gitsm fetcher instead of writing my own is that all though they are both using submodule I don't think they are related and should have a shared functionality. gitsm:// is allowing a package to have submodules, my version submodules:// is allowing a layer to have submodules. I am aware that the naming is not perfect for the intended purpose, it's a quite big difference. I personally can see a reason for using the submodule:// fetcher but I don't understand why the gitsm:// fetcher is not just an option to the git:// fetcher.

If I have understood the current implementation of gitsm it fetches information about the submodules from the main git repository. My implementation uses the local .gitmodules file for initializing and updating the submodules. For this reason we won't have to rely on the SRCREV-tag in recipes and it can be removed completely. Also as previously mentioned by Fredrik, the purpose of this patch is to introduce reproducible builds where the information is stored in git and not in the bb-files. This will significantly improve the traceability since when you are developing a package that should be integrated to the bitbake system you will no longer need to commit both to the package- and the layer repository. To solve this problem, we have developed a service that once a package is updated, the bb-file in the layer repository is automatically rewritten so match the new version of the package. But by using the layer repository as a super project it is possible to use gerrits superproject subscription that makes the layer repository to be updated each time the submodule (the package) is updated. This gives us reproducible builds, only one commit to introduce a change and no in-house developed services.