Re: [PATCH] docs: submitting-patches: Require base tree information

[Krzysztof Kozlowski <krzk@kernel.org>]

On 22/10/2026 12:04, Geert Uytterhoeven wrote:
>>
>> This is a real issue because it is very difficult to spot - your commit
>> is applied, but you never verify whether is applied THE SAME way and
>> maintainer thinks everything was applied cleanly.
>>
>> If (1) happens and patch does not apply, the solution is to ask the
>> contributor to rebase.
> 
> This happens a lot in DTS-enablement patches: multiple people are
> working on different devices for the same SoC/board, so half of their
> patches insert new device nodes at the same conflicting location.
> Perhaps we can teach to git how to handle DTS addition conflicts?
> 
> So your solution is that I apply one new patch every day and publish

We speak about special cases, where there is a conflict thus the patch
does not apply and base information could the maintainer rebase the
patch. Only this case.

> the result, and ask all other N-1 series to be rebased? Obviously this
> not only applies to queuing patches, but also to applying patches for
> build/run testing during review?

Unfortunately yes, because every other option I know, so maintainer
doing rebases, is error-prone as I see every two months. If you assume
that maintainer can be trusted in a way that they will do the rebase
correctly, then well, welcome to burnout world were we barely have time
to go through inbox, not even thinking about doing this diligently.

If we had git-forge workflow, then this (contributor need to rebase till
there is no conflict) would be even an obvious requirement enforced by
the forge.

Best regards,
Krzysztof