On Fri, Dec 19, 2025 at 04:31:25PM +0100, Matthieu Baerts wrote:
> On 19/12/2025 15:30, Mark Brown wrote:
> > On Fri, Dec 19, 2025 at 01:35:51PM +0100, Matthieu Baerts wrote:

> If 'linux-next' already contains a merge between 'net' and 'net-next',
> maybe it is fine to merge a branch also containing this merge? But I
> guess that's possibly not recommended if conflicts are solved differently.

Yeah, if the resolution is the same it's not an issue - it's if they
diverge somehow that there's a concern.

> Perhaps it is enough to work in a "best-effort" way and to provide a
> "pending-fixes" branch with only fixes on top of 'net', and "for-next"
> with patches that applies on top of "net-next". Conflicted patches are
> skipped until the next 'net' / 'net-next' sync.

You could always start with that and figure out the complicated stuff
later.

> > If you were to switch to sending a PR of the actual commits in -next
> > that'd make life easier but that'd need you to work out the workflow
> > with whoever you're sending the patches to.  I guess you could adopt a
> > hybrid flow where you use TopGit with regeneration until you send the PR
> > and then freeze the patches included in the PR?  You could use the PR as
> > a base for new stuff while it's in flight.  There are trees that are
> > managed in a patch queues that use a workflow a bit like that.

> Indeed, it might be better to do that. I will check later to put that in
> place. I guess we mainly have to change the way patches are sent.

Sounds good.