11831 2017-07-24 22:08:52 +0000 Proposal to replace/rewrite gitsm 2019-05-15 11:47:28 +0000 1 1 7 Build System, Metadata & Runtime BitBake bitbake unspecified x86 Multiple RESOLVED FIXED Medium+ enhancement Future 1 kergoth mark.hatle mark.hatle mark.jonas poky.bs.watcher poky.watcher randy.macleod rebecca.swee.fun.chang sgw --- --- Yes (doc changes required) oldest_to_newest 75265 0 kergoth 2017-07-24 22:08:52 +0000 The current gitsm implementation is naive at best, broken at worst, and lets git itself do the fetching of the submodules, so we can't use our mirror tarballs or shallow tarballs for them, among other issues, such as the already reported issue with license.bbclass. This issue is to track its replacement with a version that uses the bitbake fetcher to fetch the submodules recursively, and provides the urls of all the submodules to the metadata (likely stored as a member of the fetcher object, so anyone that needs it will have to isinstance() and grab it from there, as we can't get that information at parse time, only after the download()). We can implement direct logic to do this, or we can try implementing a fetch helper to let git call back to us to do the repository fetch for it. 76238 1 kergoth 2017-08-29 15:19:37 +0000 I've created a thus-far working prototype of a rewritten gitsm that uses the bitbake fetcher for the submodules, and am currently testing it, mulling over how to address shallow support, and starting on thorough unit tests which don't all rely on network connectivity (we can construct the repositories we need on the fly, the way we do in the shallow unit tests). See https://gist.github.com/kergoth/9c163433c33cf883b21256459d743a98 for the current implementation. 82529 2 mark.jonas 2018-12-18 09:41:24 +0000 My team is affected by this issue as well. We are looking forward to a solution. :) 83816 3 mark.hatle 2019-05-15 11:47:03 +0000 The gitsm fetcher has been refactored and rewritten to address this, locking and other issues. The code changes went into the thud version (1.40). 83817 4 mark.hatle 2019-05-15 11:47:28 +0000 resolved