On Thu, Dec 12, 2019 at 04:57:14PM +0100, Dmitry Vyukov wrote: > > Speaking of bisect hazards, I'd recommend to check how your bisect > > went - the bug is definitely local to this commit and I really > > wonder what had caused the bisect to go wrong in this particular > > case. > > I did not get the relation of folding to bisection. Or you mean these > are just separate things? Suppose instead of folding the fix in I would've done a followup commit just with the fix. And left the branch in that form, eventually getting it pulled into mainline. From that point on, *ANY* bisect stepping into the first commit would've been thrown off. For ever and ever, since once it's in mainline, it really won't go away. That's what folding avoids - accumulation of scar tissue, if you will. Sure, there's enough cases when bug is found too late - it's already in mainline or pulled into net-next or some other branch with similar "no rebase, no reorder" policy. But if you look at the patchsets posted on the lists and watch them from iteration to iteration, you'll see a _lot_ of fix-folding. IME (both by my own practice and by watching the patchsets posted by others) it outnumbers the cases when fix can't be folded by quite a factor. I wouldn't be surprised if it was an order of magnitude... Strict "never fold fixes" policy would've accelerated the accumulation of bisect hazards in the mainline. And while useful bisect may be a lost cause for CI bots, it isn't that for intelligent developers. Anything that makes it more painful is not going to be welcome.
