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

Linus Torvalds <[email protected]>
Newsgroups dev.linux.lists.regressions,org.kernel.vger.linux-bluetooth,org.kernel.vger.netdev,org.kernel.vger.stable
Message-ID <CAHk-=whwq2_iaf7pTuzVXEcJmng_exwae_bKtgSDdm4BQivGHg@mail.gmail.com>
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.

Then when your branch is all done and ready, you ask upstream (in your
case typically the networking tree) to pull it.

Some people at that point *jump* to the point where upstream merged from them.

Or another fairly common model is to have just started another branch
for future work. Keeping independent development branches for
different features is also a good thing to strive for, because it
makes it easier for different people to work on different branches
without messing with each other, but it also means that one feature
being delayed (due to unexpected problems or whatever) doesn't affect
other branches. And if done well, it also means that you wouldn't even
care about the whole "point where upstream merged", because your other
work simply isn't dependent on things like that.

So there are many ways to deal with them, but rebasing and merging are
typically the worst ones that should be avoided unless active problems
happen.

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".

Back-merges in particular need to not just be "merge upstream". They
need a commit message that explains *why* you're merging upstream (and
not merge some random point, the same way you shouldn't start
development at some random point of questionable stability).

Rebasing is "invisible" except for the mess it leaves with random
commit ids (and the problems it can cause for anybody who happened to
use an older version). So you can't explain it, but it should then be
explained to upstream why you ask them to pull recent changes that
clearly cannot have been tested in that form.

                Linus
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.