Re: [bitbake-devel] [PATCH 1/1] bitbake: add BB_GIT_SHALLOW_SKIP_FAST to disable fast shallow mode
Richard Purdie <[email protected]>
| Newsgroups | org.openembedded.lists.bitbake-devel |
|---|---|
| Message-ID | <7ac8312de40809f14006bfff65143f002543c50b.camel@linuxfoundation.org> |
On Tue, 2026-05-05 at 01:08 -0700, Marcio Henriques via lists.openembedded.org wrote: > We want to create a download mirror to store all sources needed to build a > specific project. > > The idea is to use Git shallow tarballs because each tarball has a unique name. > This prevents files from being overwritten in the mirror. With full Git > tarballs, the name is always the same, so the mirror file gets replaced each > time. If something is removed from the upstream repository, we might upload a > new tarball that no longer contains a reference used by a recipe that was > already integrated. FWIW the git fetcher is specifically coded to avoid removing references. It shouldn't remove old revisions or obsolete heads (e.g. for repos that changed master -> main). If it is doing that, that is something we should fix. > With shallow tarballs, we can safely clean DL_DIR since it's not the source of > truth. If something is removed from upstream, we fall back to the mirror and > use the shallow tarball. > > For most of the builds, we want to use the bare clone in DL_DIR/git2 and just > update the repo when bumping a SRCREV. The DL_DIR/git2 repositories are > available on the machine that triggers the build. > > The shallow tarball is a fallback for cases where something was removed from > the repository (for example, after a force push) and is not present in > DL_DIR/git2 or upstream, but was merged at some point. This is why we use Git > shallow and set shallow_skip_fast to True. I can see why you might decide to do that but it will be a pretty inefficient use of space with an archive for every revision and means turning everything into shallow clones, which has its own challenges. Cheers, Richard