15558 2024-07-24 08:31:50 +0000 SRCREV is ignored when using subpath with git fetcher 2026-04-02 09:39:41 +0000 1 1 7 Build System, Metadata & Runtime BitBake bitbake 4.0.19 x86 Multiple RESOLVED FIXED Medium+ major 6.0 M4 1 xxthegeckoxx antonin.godard jstephan poky.bs.watcher poky.watcher randy.macleod richard.purdie --- --- No (bug/feature does not impact docs) oldest_to_newest 99423 0 xxthegeckoxx 2024-07-24 08:31:50 +0000 When using the subpath in the SRC_URI, the SRCREV is not respected and the last commit of the branch is used. We're currently using poky e139e9d0ce343ba77a09601a976c92acd562c9df (kirkstone-4.0.19, BB_VERSION 2.0.0), but I also tried it with poky 688146cd1893d81dc6deed56a05250c52e6432bb (scarthgap, BB_VERSION 2.8.0). The behavior is the same. It looks like there is some issue in the git fetcher, where the checkout is skipped when using the subpath. Feel free to ask for more information if required. Greetings 101563 1 jstephan 2025-04-04 09:40:43 +0000 Hi Janik, I'm currently looking into this bug, but I haven’t been able to reproduce it on my side. Could you share a minimal example that reproduces the issue? I tried adding a subpath parameter to a Git-enabled recipe, with a specific SRCREV. Looking into tmp/work/<arch>/<package>/<version>/<subpath>, I do see the files from the subpath as they were in the commit specified by SRCREV. However, when I run git log inside that folder, it shows the latest commit of the branch instead. Also, git status reveals that all files except the subpath are marked as deleted. Could this be the source of confusion? Can you confirm whether you observe the same behavior? Or do you see the subpath files as they are in the latest commit of the branch? I can try doing some Git magic to show the log from the specified commit and clean up the staging area, resulting in a more "clean" directory — especially in a devtool environment. Would that be less confusing? Additional details: To perform the partial checkout, the Git fetcher uses low-level plumbing commands: git read-tree and git checkout-index. These commands do not update HEAD, which is fine when just building with BitBake. However, it becomes quite confusing when using devtool modify, as you’ve likely seen. @Richard – what do you think about switching to git sparse-checkout instead? It was introduced in Git 2.25 but is still marked as an experimental feature even in recent versions [1]. Personally, I think we should hold off on switching to it — at least for now. Cheers, Julien [1] https://git-scm.com/docs/git-sparse-checkout/2.42.0 101565 2 xxthegeckoxx 2025-04-04 14:37:26 +0000 Hi Julien This is in fact an interessting theorie. We build our software inside of yocto and build in the commit hash which is then shown on a display. This is how I found the "bug". If the git tool reports the commit hash of the latest commit, it's possible, that this one was build in instead of the "real" one which is in the SRCREV. Switching away from the subpath fixed then the problem. I will verify if this is correct. You will hear from me. Greetings Janik 101904 3 xxthegeckoxx 2025-05-08 11:18:25 +0000 Hi Julien I was able to confirm, what you explained. When using the subpath option, the commit hash git reports don't change, but the status of the folder is the one expected from the commit hash of the SRCREV. So I confirm your observed behavior. For me personally, I would also not switch to the experimental feature of git. I'm also hesitating in changing the behavior with some "git magic" as you described. A `git reset --soft` to the specific commit works, but still shows all the other files as deleted with git status, which still could be confusing. What could maybe help, is a disclaimer in the git fetcher section of the BitBake manual, which says that the HEAD don't get updated. My conclusion would be: Some information in the documentation could help preventing others running into the same confusion as I did, but otherwise I think we could close the issue. Greetings Janik 104536 4 randy.macleod 2026-03-05 16:18:32 +0000 Antonin, Is there a code changed needed or only docs ? 104540 5 richard.purdie 2026-03-05 16:41:49 +0000 It sounds like the behaviour is correct but the head revision being reported by git is confusing. At the very least we need to document that so copy Antonin for that piece. I'm not sure if it is possible to change the fetcher code to improve things or not. We certainly don't want to use experimental git features though. 104806 6 antonin.godard 2026-03-26 08:55:50 +0000 Patch sent on bitbake list to document this behavior: https://lore.kernel.org/r/20260326-add-subpath-warning-v1-1-ece919e8779a@bootlin.com 104923 7 antonin.godard 2026-04-02 09:39:41 +0000 Patch merged: https://git.openembedded.org/bitbake/commit/?id=7c42f89fb7d5e9e19434d199415738e0ad79e79c