Re: [MAINTAINERS SUMMIT] Any feedback for -next?

["Uwe Kleine-König" <u.kleine-koenig@baylibre.com>]

[-- Attachment #1: Type: text/plain, Size: 2128 bytes --]

On Mon, Aug 24, 2026 at 12:07:08PM +0200, Vlastimil Babka wrote:
> On 8/13/26 14:36, Mark Brown wrote:
> > On Thu, Aug 13, 2026 at 09:31:58AM +0200, Geert Uytterhoeven wrote:
> >> On Wed, 12 Aug 2026 at 18:44, Mark Brown <broonie@debian.org> wrote:
> > 
> >> > > The advantage is that if commit B breaks something there are less
> >> > > intermediate trees that don't contain B and you can still test on e.g.
> >> > > D+E.
> > 
> >> Sounds like a nice idea to me!
> >> And you can put the trees that usually cause the most conflicts in
> >> the same subgroup ;-)
> > 
> >> It may also help in bisecting an issue.  I have the impression "git
> >> bisect" on linux-next (against Linus' tree, not against yesterday's
> >> next) shows me more "a merge base must be tested" test points than
> >> expected/optimal.
> > 
> > IME it tends to walk down the linear history of -next until it find
> > which branch introduced the regression.  I've never investigated in
> > detail but my feeling is that the inefficiency is more driven by the
> > size of the branch it lands on.
> 
> When bisecting -next, I actually use the "git bisect --first-parent" mode
> first explicitly to find the culprit branch (or precisely, its merge), then
> do a second bisect only within it. It avoids wild changes of the tree
> between bisection steps due to the differing bases.

TIL `git bisect --first-parent`, thanks.

> The suggested binary tree merging approach would make this strategy somewhat
> more difficult.

The argument could be somewhat weakend by first merging linus/master
into each next tree and only then start merging using the binary
approach. (Then bisection could be done without the base changes, `git
bisect` wouldn't necessarily do that though. It could be directed to do
that by marking all trees (i.e. before merging linus/master into them)
as good for the first run.)

Thinking further, having $tree+linus/master for each tree can be
beneficial in some situations. But that could also be done with the
current merge order. Not sure though if it's worth the effort.

Best regards
Uwe

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]