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

[Sasha Levin]

On Tue, Dec 23, 2025 at 05:47:58PM +0000, Mark Brown wrote:
> On Tue, Dec 23, 2025 at 07:36:18AM -0500, Sasha Levin wrote:
> > On Mon, Dec 22, 2025 at 02:50:55PM +0000, Mark Brown wrote:
> > > On Sun, Dec 21, 2025 at 11:10:11AM -0500, Sasha Levin wrote:
>
> > > 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.
>
> > My thinking around it was to enable faster per-subsystem tests than what we
> > currently do. For example, we can quickly build mm-next and run mm focused
> > tests on it.
>
> If we start putting everything into intermediate merges then inevitably
> some of those merges are going to be later in the process and will get
> generated later in the process, meaning they're nearer to the production
> of the full -next.  I'm also not clear that we have enough trees that
> would update multiple times a day.

I've left the script running over the holiday break, and the rate of changes is
very surprisingly high (specially given it was a holiday in most of the
world!).

> > Since creating these per-subsystem trees is fairly cheap and can happen even
> > few times a day, we can help identify issues way earlier during the process.
>
> To be clear unless things are super prone to conflicts the big cost with
> adding stuff to -next isn't generally doing the merges, it's build
> testing the results.  To that end the main potential advantage I can see
> in doing submerges would be if we could parallelise the build testing
> portion of things.  That would need some consideration of the complexity
> of the scripting, the build machines and the cogantive load involved,
> and if we were doing that the considerations for constructing submerges
> would be a bit different.  It has crossed my mind, but it'd be non
> trivial to do and not intending to produce intermediate merges that are
> useful to anyone else.

The way I have it working is that I will only recreate a sub-tree if any of the
-next trees that are part of it were rebased, otherwise I will just merge new
changes on top of the existing tree.

I will also do a build test only after I merged everything into the sub-tree.
If we hit a build error, I will bisect between the last known good point and
HEAD.

Between the above, as well as tracking "known-broken" trees, the volume of
build tests is not that scary.

--
Thanks,
Sasha