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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.