Re: [yocto] Bitbake fetch does not re-fetch from network if gitrepo is found in DL_DIR

[Gyorgy Sarvari <skandigraun@gmail.com>]

I have been thinking about this, and also tried to reproduce it,
unsuccessfully...

If fetch is deemed successful, it is stored in the shared state cache,
and then it is not repeated until the relevant signature changes - I
think this is the metadata reference you found.
However as long as the download folder's content is only modified by one
project only, it supposed keep track of it fine.

One question about the DL_DIR: is it possible that it is shared between
multiple projects, while keeping separate shared state cache? Or that
the DL_DIR's content modified manually?
The shared state cache supposed to keep track of what is downloaded by
bitbake and what is not, but if the DL_DIR's content is changed without
bitbake (or by a separate bitbake), that can break the shared state, and
cause such issues.

On 12/4/25 22:41, christian.leeb via Lists.Yoctoproject.Org wrote:
> I'm using Yocto 4.0, kirkstone.
>  
> We set
> URI is
> git://dev.azure.com/PG-CT/PGLinux/_git/pg-linux;protocol=https;branch=pg-am57xx-ti-rt-linux-5.4.106
> SRCREV="7818dfe57e1d1e2d2eaf039d1231560611811d67"
> BRANCH="pg-am57xx-ti-rt-linux-5.4.106"
>
> The DL_DIR contains above repo
> (git2/dev.azure.com.PG-CT.PGLinux._git.pg-linux) and above branch but
> just not the latest commit of this branch.
> Also, between 
> recipe linux-ti-staging-rt-5.4.106+gitAUTOINC+7818dfe57e-r7a.spark10:
> task do_fetch: Started
> and
> recipe linux-ti-staging-rt-5.4.106+gitAUTOINC+7818dfe57e-r7a.spark10:
> task do_fetch: Succeeded
> there is only a few seconds. Another proof IMHO that there was no
> network access.
>
> Fetch works properly if the repo is not present at all in the DL_DIR.
>
> I also check if shallow clone is set: seems that this is not the case
> unless there is some other setting to consider.
>
> bitbake virtual/kernel -e | grep ^BB_GIT_SHALLOW
> BB_GIT_SHALLOW:pn-binutils="1"
> BB_GIT_SHALLOW:pn-binutils-cross-arm="1"
> BB_GIT_SHALLOW:pn-binutils-cross-canadian-arm="1"
> BB_GIT_SHALLOW:pn-binutils-cross-testsuite="1"
> BB_GIT_SHALLOW:pn-binutils-crosssdk-x86_64-spark-linux="1"
> BB_GIT_SHALLOW:pn-binutils-native="1"
> BB_GIT_SHALLOW:pn-glibc="1"
>
> In addition I got this info from the internet:
> /Why do_fetch didn’t update the repo:/
> /BitBake’s fetcher logic:/
> /If the repo exists in DL_DIR and the SRCREV is marked as available
> (based on metadata), it skips network fetch./
> /It doesn’t *verify the actual commit presence during do_fetch*—that
> check happens in do_unpack./
> /So the 2-second fetch means it reused the cached repo without pulling
> new commits./
>
> I wonder what it means "/SRCREV is marked as available (based on
> metadata)/". It's obviously not there.
>
> Thanks a lot for your support.
>
> Chris
>