[bitbake][lib/bb/fetch2/git.py] Re-introducing --prune option in fetch_cmd #bitbake

[bitbake][lib/bb/fetch2/git.py] Re-introducing --prune option in fetch_cmd #bitbake

[Bruno Ferreira]

[-- Attachment #1: Type: text/plain, Size: 1321 bytes --]

Hi,

In my current project we have several repositories where developers use git branch references in the format:

> 
> /remotes/origin/foo
> /remotes/origin/foo/bar
> 

And sometimes parent references, e.g: "/remotes/origin/foo" get deleted from the upstream repository leading to git fetch issues.

> 
> error: cannot lock ref 'refs/heads/foo/bar': 'refs/heads/foo' exists;
> cannot create 'refs/heads/foo/bar'
> 

Typically, the way git handles these cases is by adding the *--prune* option to delete the stale references from the local references and fetching would work.

While investigating what bitbake currently does during fetching for git repositories I've found the current fetch command ( https://git.yoctoproject.org/poky/tree/bitbake/lib/bb/fetch2/git.py?h=scarthgap#n459 ) in the past had the --prune option ( https://git.yoctoproject.org/poky/commit/?id=61931d14df3be5273a38008ae2dff2a60a7d9b02 )
but it was removed due to breaking old releases.

My first question is, is it ok to bring back the *--prune* option to *fetch_cmd* or this will still be an issue and it will brake old releases?

Second question, if introducing *--prune* again is not an option, what would be the recommend approach to introduce this setting via a configuration option on git.py lib?

Thank you,
B.

[-- Attachment #2: Type: text/html, Size: 2751 bytes --]

Re: [bitbake-devel] [bitbake][lib/bb/fetch2/git.py] Re-introducing --prune option in fetch_cmd #bitbake

[Alexander Kanavin]

On Mon, 9 Feb 2026 at 17:32, Bruno Ferreira via lists.openembedded.org
<srbruno=gmail.com@lists.openembedded.org> wrote:
> In my current project we have several repositories where developers use git branch references in the format:
>
>
> /remotes/origin/foo
> /remotes/origin/foo/bar
>
>
> And sometimes parent references, e.g: "/remotes/origin/foo" get deleted from the upstream repository leading to git fetch issues.
>
>
> error: cannot lock ref 'refs/heads/foo/bar': 'refs/heads/foo' exists; cannot create 'refs/heads/foo/bar'
>
>
> Typically, the way git handles these cases is by adding the --prune option to delete the stale references from the local references and fetching would work.
>
> While investigating what bitbake currently does during fetching for git repositories I've found the current fetch command in the past had the --prune option
> but it was removed due to breaking old releases.
>
> My first question is, is it ok to bring back the --prune option to fetch_cmd or this will still be an issue and it will brake old releases?
>
> Second question, if introducing --prune again is not an option, what would be the recommend approach to introduce this setting via a configuration option on git.py lib?

New fetcher configuration options aren't particularly welcome, as they
need documentation, tests, and create alternative code paths and
complexity.

Perhaps it would help if you show the sequence of steps that leads to
breakage, as it's hard to tell from just the description above what
the problem is exactly.

Alex

Re: [bitbake][lib/bb/fetch2/git.py] Re-introducing --prune option in fetch_cmd #bitbake

[Bruno Ferreira]

[-- Attachment #1: Type: text/plain, Size: 1929 bytes --]

> 
> New fetcher configuration options aren't particularly welcome, as they
> need documentation, tests, and create alternative code paths and
> complexity.
> 

That confirms my initial expectations, thanks for clarifying it.

> 
> Perhaps it would help if you show the sequence of steps that leads to
> breakage, as it's hard to tell from just the description above what
> the problem is exactly.
> 
> 

Sure. So first of all this is a git "problem" not a bitbake fetcher git.py lib "problem".

A developer created an upstream branch named "foo" with code changes
and changed a recipe SRC_URI to use the following:

SRC_URI = git://github.com/org/random-repo.git;protocol=https;branch=foo

do_fetch task was able to fetch everything properly during recipe build, storing it in DL_DIR as expected.

Second developer created the upstream branch "foo/bar" with code changes.
Meanwhile the first developer deleted the branch "foo" upstream.

The second developer updated the recipe to use the new branch:

SRC_URI = git://github.com/org/random-repo.git;protocol=https;branch=foo/bar

During do_fetch, git is not able to fetch the "foo/bar" branch as the parent reference "foo"
no longer exists in the upstream repo (only exists on local) triggering the error visible in the log.do_fetch

> 
> error: cannot lock ref 'refs/heads/foo/bar': 'refs/heads/foo' exists;
> cannot create 'refs/heads/foo/bar'
> From https://github.com/org/random-repo
> ! [new branch]      foo/bar -> foo/bar  (unable to update local ref)
> 

If I add back the --prune option that was removed here ( https://git.yoctoproject.org/poky/commit/?id=61931d14df3be5273a38008ae2dff2a60a7d9b02 ) , "git fetch" will work with the following message
will appear in log.do_fetch

> 
> From https://github.com/org/random-repo
> - [deleted]         (none)     -> foo
> * [new branch]      foo/bar -> foo/bar
>

[-- Attachment #2: Type: text/html, Size: 2731 bytes --]

Re: [bitbake-devel] [bitbake][lib/bb/fetch2/git.py] Re-introducing --prune option in fetch_cmd #bitbake

[Alexander Kanavin]

On Tue, 10 Feb 2026 at 12:29, Bruno Ferreira via
lists.openembedded.org <srbruno=gmail.com@lists.openembedded.org>
wrote:
> If I add back the --prune option that was removed here, "git fetch" will work with the following message
> will appear in log.do_fetch
>
> From https://github.com/org/random-repo
> - [deleted]         (none)     -> foo
> * [new branch]      foo/bar -> foo/bar

The option was removed for good reasons, we can't simply discard those
reasons. I think that change was prompted by mass master -> main
renames?

I'd say you simply have to ask developers to namespace their branches
properly and don't step on each other; once there is a branch named
foo, one cannot anymore create a branch foo/bar, and vice versa. It's
caused by how git stores branch information in .git/refs/heads/ - the
slash-separated parts of the branch name become directories. Usually
branch names are prefixed with developer's nicknames for this reason.

One could also argue that once there is a revision of some recipe in
commit history that refers to a particular branch, that branch should
not be deleted so that the repository with the recipe remains
bisectable.

Alex

Re: [bitbake][lib/bb/fetch2/git.py] Re-introducing --prune option in fetch_cmd #bitbake

[Bruno Ferreira]

[-- Attachment #1: Type: text/plain, Size: 1262 bytes --]

> 
> I'd say you simply have to ask developers to namespace their branches
> properly and don't step on each other; once there is a branch named
> foo, one cannot anymore create a branch foo/bar, and vice versa.
> 

The problem is not asking but more on the enforcing part specially when developers
are able to use this workflow outside bitbake without any issues.

Another upstream branch creation flow that triggers the fetch issue that doesn't
involve to explicitly set the branch in the recipe (as the first example that I provided):

* bitbake <recipe> -c do_fetch --no-setscene with branch "main" and SRCREV = aaa
* Created upstream branch "foo"
* bitbake <recipe> -c do_fetch --no-setscene with branch "main" and SRCREV = bbb (to double confirm that it fetch all the references upstream)
* Deleted upstream branch "foo"
* Created upstream branch "foo/bar"
* bitbake <recipe> -c do_fetch --no-setscene with branch "main" and SRCREV = ccc (to double confirm that it fetch all the references upstream)
* Fetch failed with error: cannot lock ref 'refs/heads/foo/bar': 'refs/heads/foo' exists; cannot create 'refs/heads/foo/bar'

A developer can create a upstream temporary branch and trigger this even if they are not aware of the issue.

[-- Attachment #2: Type: text/html, Size: 1514 bytes --]

RE: [bitbake-devel] [bitbake][lib/bb/fetch2/git.py] Re-introducing --prune option in fetch_cmd #bitbake

[Peter Kjellerstedt]

[-- Attachment #1: Type: text/plain, Size: 2373 bytes --]

If we add back the --prune option, the download cache will become broken and it will no longer be possible to build old recipes that refer to master branches that have been renamed to main. This has serious impacts for us that need to be able to rebuild old releases of our software.
On the other hand, the workaround for the problem you describe below is to simply run bitbake <recipe> -c cleanall. And while this may be annoying, it only affects those who are directly affected by the specific repository, and has no global impact on the rest of us.

//Peter

From: bitbake-devel@lists.openembedded.org <bitbake-devel@lists.openembedded.org> On Behalf Of Bruno Ferreira via lists.openembedded.org
Sent: den 19 februari 2026 11:35
To: bitbake-devel@lists.openembedded.org
Subject: Re: [bitbake-devel] [bitbake][lib/bb/fetch2/git.py] Re-introducing --prune option in fetch_cmd #bitbake

You don't often get email from srbruno=gmail.com@lists.openembedded.org<mailto:srbruno=gmail.com@lists.openembedded.org>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
I'd say you simply have to ask developers to namespace their branches
properly and don't step on each other; once there is a branch named
foo, one cannot anymore create a branch foo/bar, and vice versa.
The problem is not asking but more on the enforcing part specially when developers
are able to use this workflow outside bitbake without any issues.

Another upstream branch creation flow that triggers the fetch issue that doesn't
involve to explicitly set the branch in the recipe (as the first example that I provided):


  *   bitbake <recipe> -c do_fetch --no-setscene with branch "main" and SRCREV = aaa
  *   Created upstream branch "foo"
  *   bitbake <recipe> -c do_fetch --no-setscene with branch "main" and SRCREV = bbb (to double confirm that it fetch all the references upstream)
  *   Deleted upstream branch "foo"
  *   Created upstream branch "foo/bar"
  *   bitbake <recipe> -c do_fetch --no-setscene with branch "main" and SRCREV = ccc (to double confirm that it fetch all the references upstream)
  *   Fetch failed with error: cannot lock ref 'refs/heads/foo/bar': 'refs/heads/foo' exists; cannot create 'refs/heads/foo/bar'

A developer can create a upstream temporary branch and trigger this even if they are not aware of the issue.


[-- Attachment #2: Type: text/html, Size: 13501 bytes --]