On Sun, 3 Aug 2025 at 06:18, Daniel Gomez <da.go...@kernel.org> wrote:
>
> Note that this had a conflict with sysctl changes [1] but should be fixed now
> as I
> rebased on top.
Christ people.
Read the documentation and *years* of me sending out emails about what
maintainers should do. Conflicts are *not* a reason to rebase.
See
Documentation/maintainer/rebasing-and-merging.rst
and read it. Read it twice. Then read it again until you really *UNDERSTAND* it.
I deal with conflicts all the time, and that was a particularly
_trivial_ one. I'd *much* rather see a conflict and know that "yeah,
we had people working in the same area this time around" than have it
hidden by a rebase that also invalidates all the testing it got
pre-rebase.
And yes, that "invalidates all the testing" is not just some
theoretical thing. We've literally had situations where tested code
became "oops, now it doesn't work because we rebased it on top of a
tree that had different assumptions".
Is that common? No. But it's just one - of many - reasons not to
rebase, and "it had a conflict" is *NOT* a big enough reason to then
think that rebasing is better.
So "it has a conflict" is real information about the development
process, and shouldn't be hidden.
Yes, there are conflicts that are *so* painful that rebasing things is
worth it. This was not it.
And this rebase was particularly bad. You did *everything* wrong. Not
only was there not a good reason for it, you picked a starting point
that is KNOWN BUGGY AND BOOTS TO A BLACK SCREEN ON MY MACHINE. So now
your new work is basically built on top of something known broken, and
as a result, all *your* commits are known broken too, even if that
breakage isn't due to those commits themselves.
So your rebased state is all built on a base of sand, instead of
something good and stable. And if somebody ends up having to bisect
this because of something it introduces (or even just happens to
bisect into this area for some *unrelated* reason), you picking that
random - and bad - base means that now that bisection is potentially
much more painful than it needed to be.
And yes, this is also talked about in the documentation:
"If you must reparent a repository, do not pick some random kernel commit
as the new base. The kernel is often in a relatively unstable state
between release points; basing development on one of those points
increases the chances of running into surprising bugs. When a patch
series must move to a new base, pick a stable point (such as one of
the -rc releases) to move to"
I've pulled this, because I'm flying out tomorrow, and it otherwise
looks fairly simple and straightforward.
But dammit. DO NOT MINDLESSLY REBASE YOUR TREES!
Linus
