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