linux-kernel - Re: [PATCH v2] docs: bug-bisect: rewrite to better match the other bisecting text

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20240821210226.25862313@mordecai>
Date: Wed, 21 Aug 2024 21:02:26 +0200
From: Petr Tesarik <ptesarik@...e.com>
To: Thorsten Leemhuis <linux@...mhuis.info>
Cc: Jonathan Corbet <corbet@....net>, regressions@...ts.linux.dev,
 linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org, Bagas Sanjaya
 <bagasdotme@...il.com>
Subject: Re: [PATCH v2] docs: bug-bisect: rewrite to better match the other
 bisecting text

On Tue, 20 Aug 2024 19:16:25 +0200
Thorsten Leemhuis <linux@...mhuis.info> wrote:

> On 20.08.24 14:07, Petr Tesarik wrote:
> > On Sun, 18 Aug 2024 18:12:13 +0200
> > Thorsten Leemhuis <linux@...mhuis.info> 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