Thread (18 messages) 18 messages, 3 authors, 11d ago

Re: [GIT PULL] bluetooth 2026-09-07

From: Mark Brown <broonie@kernel.org>
Date: 2026-09-15 19:24:30
Also in: linux-bluetooth

On Tue, Sep 15, 2026 at 03:16:21PM -0400, Luiz Augusto von Dentz wrote:
On Tue, Sep 15, 2026 at 2:26 PM Mark Brown [off-list ref] wrote:
quoted
Given the issues caused by the unusual workflow for the tree I do send a
lot of reports of issues in bluetooth.
Are you referring to the unusual workflow where fixes are merged to
bluetooth-next first, then to bluetooth (which changes its ID), and
finally merge to net? Changing the order to have Bluetooth first and
then bluetooth-next would require reworking the CI so it could
determine that it is a fix and then use Bluetooth as a base just to
avoid ID changes.
Yes, the routine cherry picking is certainly part of it - it's not so
much the fact that things get moved between branches as the fact that
when you have the same commit is in multiple branches and then build on
top of one or both of them this creates extra conflicts, often harder to
understand, when the branches are merged.  The more normal thing would
be to apply once to the right place, or the standard fallback from that
would be to drop the commit from branch A at the time it is moved to
branch B.

You do seem to end up removing the cherry picked commits from their
original branches at some point as part of your workflow (since there
are hardly any duplicate bluetooth commits in mainline) so they do wind
up being moves AFAICT but the duplicates get left sitting there for
quite a while.

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help