On Tue, 20 Aug 2024 19:16:25 +0200 Thorsten Leemhuis <linux@xxxxxxxxxxxxx> wrote: > 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. That's just as good for me. Keep your wording. > >> + 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). Good point. I don't have a strong opinion either, so let's go with "series". > > > 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. Yes, this makes it crystal clear what I am supposed to do. > > 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! No problem. It's you who has done the hard work. Petr T
