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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e6681b51-297e-4ef8-a199-d36712088740@leemhuis.info>
Date: Tue, 20 Aug 2024 19:16:25 +0200
From: Thorsten Leemhuis <linux@...mhuis.info>
To: Petr Tesarik <ptesarik@...e.com>
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 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. 

>> +  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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ