Re: [RFC 0/5] LLMinus: LLM-Assisted Merge Conflict Resolution

Mark Brown
2025-12-22T14:50:59Z

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

On Sun, Dec 21, 2025 at 11:10:11AM -0500, Sasha Levin wrote:

> I assigned categories to the various trees used by -next (see
> https://gist.github.com/sashalevin/163df4ae1163e0e22a97edc40e14b7f5) and built
> a simple wrapper script to generate per-category integration branches, letting
> LLMinus resolve conflicts whenever we hit one.

Those categories appear to be a bit randomly assigned FWIW. I'm not
clear who would want the various intermediate merges either, I suppose
that having some of the trees pulled into multiple places might help
shake out some of the issues due to things getting sent to Linus in a
different order but OTOH it will increase the total number of merges
done and tested which is itself a cost. We could also shake out
ordering issues by doing something like randomise the ordering. I think
I'd want some demand or use case for doing more intermediate merges
rather than just doing a bunch of them for the sake of it.

This seems like a very separate experiment to your LLM merge thing.

> The resulting branches were pushed to
> https://git.kernel.org/pub/scm/linux/kernel/git/sashal/linux-next.git/refs/ .
> Each category has a %s-next branch, and a larger all-next branch which merges
> all of them together and is the equivalent of linux-next.

> Please let me know what you think!

It might be easier to tell what it's done if you ran this with the same
inputs as the last -next (it's on Christmas break at the minute),
there's quite large differences in the end result but most if not all of
that is that the input trees you're using are fresher than the last
-next. Though I think even with the same base there'd be a bit of a
needle in a haystack thing finding interesting cases, probably it'd be
more useful to find and highlight specific cases where it does something
interesting.

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