On 22.10.24 17:59, Mark Brown wrote: > We don't explicitly mention anywhere in the kernel tree that bisects > between -next versions won't work well and it's better to bisect between > mainline and -next. Let's add a note about that to try to help people avoid > this particular gotcha. > > Signed-off-by: Mark Brown <broonie@xxxxxxxxxx> Thx for this! > --- > Documentation/admin-guide/bug-bisect.rst | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > [...] > +Bisecting linux-next > +-------------------- > + > +Since linux-next is a series of merges rebuilt every day starting from > +Linus' tree there is no commmon history between multiple versions of > +-next. This means that the history of a given -next release won't > +include prior -next releases which confuses bisect if you try to > +bisect between them. Bisects will run much better if performed between > +-next and the commit in Linus' tree which that version of -next is > +based on instead. Hmmmm. That describes the problem (somewhat in style of a "reference guide"), but does not really match the approach the rest of the text uses (which is more of an "howto"). So for me it feels like a bad fit, even if users of linux-next are less likely to need a howto. How about something like this instead: --- Bisecting linux-next -------------------- If you face a problem that only happens in linux-next, bisect between the linux-next branches "stable" and "master". Use these commands to start the bisection for a linux-next tree you added as a remote called "next":: git bisect start git bisect good next/stable git bisect bad next/master The "stable" branch refers to the state of linux-mainline the current linux-next release is based on -- so it should be free of any problems that show up in -next, but not in Linus' tree. This approach will mean that you have to bisect across a wide range of changes, some of which you might have used in earlier linux-next releases without problems. Sadly it's impossible to bisect from one linux-next release to a later one (say between next-20241022 and next-20241023), as the -next specific changes of the two share no common history. --- I did not check the commands in that text yet, hope I did not do anything stupid there. Ciao, Thorsten
