Re: [tip: locking/core] compiler-context-analysis: Bump required Clang version to 23

[Niklas Cassel <cassel@kernel.org>]

On Thu, May 28, 2026 at 12:27:03PM +0200, Peter Zijlstra wrote:
> On Thu, May 28, 2026 at 11:37:22AM +0200, Peter Zijlstra wrote:
> 
> > > Would it be possible for you to provide an immutable branch with only
> > > this specific commit, such that I could merge that immutable branch to
> > > libata/for-next (such that we carry the exact same SHA1) in both trees?
> > 
> > I think that means I have to rebase tip/locking/core; pull out that
> > patch and stick it in a separate branch and then merge the two branches,
> > right? Git and me never really get along well.
> > 
> > Let me see if I can do this without destroying stuff :-)

Hehe :)

It gives me a smile that you can debug intricate scheduler bugs,
but get worried about a simple git rebase :)


> 
> So I think I managed; there should now be tip/locking/context with just
> the one commit in and tip/locking/core has an extra merge commit.
> 
> Bit ugly, but I've no idea if this can be done better.

It is correct, old locking/core and new locking/core are identical:
$ git diff 43a037d4fa6d tip/locking/core

I don't think it can be done in a nicer way.
(Yes, locking/core could be rebased on top of locking/context,
but I don't think that is nicer, as it would hides things.)

Just to be explicit: I assume that I have your approval to also carry this
single/exact SHA1:
f45c5c4adb27 ("compiler-context-analysis: Bump required Clang version to 23")

in the libata tree, such that it does not matter which pull request Linus
merges first.

Thank you Peter!


Kind regards,
Niklas