Re: [GIT PULL] bluetooth 2026-05-14

On 5/20/26 21:32, Linus Torvalds wrote:
> On Wed, 20 May 2026 at 08:53, Luiz Augusto von Dentz
> <[email protected]> wrote:
>>> Just never rebase any public tree please.
>> I guess the alternative is to do merges, right?
> No. Back-merges are bad too, unless they have a really damn solid
> reason for them, and some "keep up with other peoples work" is not
> that.
> 
> The primary model should be that you care about your own work, and
> make sure that that is as stable as possible. Do *NOT* try to chase
> other people's work. Not with merges, not with rebases. [...]
> [...]
> Sometimes you have to rebase because of a mistake. Sometimes you need
> to do back-merges. But you should damn well have *reasons* for both
> that aren't "that's just how we work".

Speaking of mistakes, one happens occasionally that you afaics did not
cover here. And it's one where I'd be interested in your opinion (and
maybe Greg's from the stable perspective, too):

How to deal with cases where one fix was merged to a public -next branch
for merging in the next cycle (and thus was mixed up with many
non-fixes) but then turns out should be mainlined this cycle?

I notice such situations a few times per month. I just had exactly that
case for a patch fixing a 7.0 regression. And the answer I got was round
about "sorry, the fix is already in our -next tree, we thus can't merge
it this cycle"[1]. And that seemed wrong to me, which is why I argued
for cherry-picking in that case, but it seems I was not convincing.

And yes, I understand that cherry-picking causes pain (especially for
the stable team) and thus is best avoided -- but mistakes like that will
always happen, so it might be best to know what to do in that case.

> [...]

Ciao, Thorsten

[1] it's for a regression introduced in the 7.0 cycle:
https://lore.kernel.org/all/[email protected]/
-- the tree in question afaics is not even in -next, as I can't see the
fix there