On 20.08.24 14:07, Petr Tesarik wrote: > On Sun, 18 Aug 2024 18:12:13 +0200 > Thorsten Leemhuis <linux@xxxxxxxxxxxxx> wrote: > >> Rewrite the short document on bisecting kernel bugs. The new text >> improves .config handling, brings a mention of 'git skip', and explains > Nitpick: git bisect skip Ohh, one of those cases where one misses the most obvious mistakes. Thx for pointing this out! Also: many thx for your feedback in general, performed a most of the changes you suggested (thx again), only replying to a few other bits. > But it's still difficult to parse for me. Maybe it would be better to > reorder the sentence like this: > > After issuing one of these commands, if Git checks out another > bisection point and prints something like 'Bisecting: 675 revisions > left to test affter this (roughly 10 steps)', then go back to step 1. Chose to do it slightly different: After issuing one of these two commands, Git will usually check out another bisection point and print something like 'Bisecting: 675 revisions left to test after this (roughly 10 steps)'. In that case go back to step 1. >> + Git might reject this, for example when the bisection landed on a merge >> + commit. In that case, abandon the attempt. Do the same, if Git fails to revert >> + the culprit on its own because later changes depend on it -- at least unless >> + you bisected using a stable or longterm kernel series, in which case you want >> + to retry using the latest code from that series. > > Admittedly, this paragraph left me a bit confused. So, what is your > suggestion if I bisected using a stable or longterm kernel series (BTW > shouldn't we use Git-speak and call it a branch?) Not having a strong opinion here, but I'd say "series" is the better word here; but maybe "using" should go (see below). > and Git fails to > revert the commit because some later changes depend on the commit? > Are you trying to say I should check out the current head of that > stable or longterm branch and retry the revert there? Yeah. Changed the text slightly; does it make things better? Git might reject this, for example when the bisection landed on a merge commit. In that case, abandon the attempt. Do the same, if Git fails to revert the culprit on its own because later changes depend on it -- at least unless you bisected a stable or longterm kernel series, in which case you want to check out its latest codebase and try a revert there. > Overall, it all looks good to me. > Thank you very much for your effort! Thx for saying that, the time your spend, and your feedback, much appreciated! Ciao, Thorsten
