From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1C113E9A03B for ; Thu, 19 Feb 2026 10:35:34 +0000 (UTC) Subject: Re: [bitbake][lib/bb/fetch2/git.py] Re-introducing --prune option in fetch_cmd #bitbake To: bitbake-devel@lists.openembedded.org From: "Bruno Ferreira" X-Originating-Location: Porto, PT (78.137.195.170) X-Originating-Platform: Mac Firefox 147 User-Agent: GROUPS.IO Web Poster MIME-Version: 1.0 Date: Thu, 19 Feb 2026 02:35:29 -0800 References: <660988.1770722998965341769@lists.openembedded.org> In-Reply-To: Message-ID: <991492.1771497329296933851@lists.openembedded.org> Content-Type: multipart/alternative; boundary="nNupDBUGQ5sjpyxwtt8r" List-Id: X-Webhook-Received: from 45-33-107-173.ip.linodeusercontent.com [45.33.107.173] by aws-us-west-2-korg-lkml-1.web.codeaurora.org with HTTPS for ; Thu, 19 Feb 2026 10:35:34 -0000 X-Groupsio-URL: https://lists.openembedded.org/g/bitbake-devel/message/19066 --nNupDBUGQ5sjpyxwtt8r Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable >=20 > 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. >=20 The problem is not asking but more on the enforcing part specially when dev= elopers are able to use this workflow outside bitbake without any issues. Another upstream branch creation flow that triggers the fetch issue that do= esn't involve to explicitly set the branch in the recipe (as the first example th= at I provided): * bitbake -c do_fetch --no-setscene with branch "main" and SRCREV = =3D aaa * Created upstream branch "foo" * bitbake -c do_fetch --no-setscene with branch "main" and SRCREV = =3D bbb (to double confirm that it fetch all the references upstream) * Deleted upstream branch "foo" * Created upstream branch "foo/bar" * bitbake -c do_fetch --no-setscene with branch "main" and SRCREV = =3D ccc (to double confirm that it fetch all the references upstream) * Fetch failed with error: cannot lock ref 'refs/heads/foo/bar': 'refs/head= s/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. --nNupDBUGQ5sjpyxwtt8r Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
I'd say you simply have to ask developers to namespace their branches<= br />properly and don't step on each other; once there is a branch namedfoo, one cannot anymore create a branch foo/bar, and vice versa.
The problem is not asking but more on the enforcing part specially whe= n developers
are able to use this workflow outside bitbake without any issues.
 
Another upstream branch creation flow that triggers the fetch issue th= at doesn't
involve to explicitly set the branch in the recipe (as the first examp= le that I provided):
 
  • bitbake <recipe> -c do_fetch --no-setscene with branch "main" and= SRCREV =3D aaa
  • Created upstream branch "foo"
  • bitbake <recipe> -c do_fetch --no-setscene with branch "main" and= SRCREV =3D bbb (to double confirm that it fetch all the references upstrea= m)
  • Deleted upstream branch "foo"
  • Created upstream branch "foo/bar"
  • bitbake <recipe> -c do_fetch --no-setscene with branch "main" and= SRCREV =3D ccc (to double confirm that it fetch all the references upstrea= m)
  • Fetch failed with error: cannot lock ref 'refs/heads/foo/bar': 'refs/he= ads/foo' exists; cannot create 'refs/heads/foo/bar'
 
A developer can create a upstream temporary branch and trigger this ev= en if they are not aware of the issue.
 
--nNupDBUGQ5sjpyxwtt8r--