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

[Krzysztof Kozlowski]

On 21/10/2026 08:49, Eric Biggers wrote:
> On Wed, Oct 21, 2026 at 08:41:47AM +0200, Krzysztof Kozlowski wrote:
>> On 21/10/2026 08:39, Eric Biggers wrote:
>>> On Wed, Oct 21, 2026 at 08:26:28AM +0200, Krzysztof Kozlowski wrote:
>>>> On 20/10/2026 23:22, Eric Biggers wrote:
>>>>> -Make sure that base commit is in an official maintainer/mainline tree
>>>>> -and not in some internal, accessible only to you tree - otherwise it
>>>>> -would be worthless.
>>>>> +    If ``git format-patch`` with ``--base=auto`` (or
>>>>> +    ``format.useAutoBase=true``) can't detect a base commit, e.g. due to
>>>>> +    the current branch having no upstream tracking branch, it exits with
>>>>> +    an error. In such cases, pass an explicit base commit to ``--base``
>>>>> +    instead. This is also needed if git detects the wrong base commit,
>>>>> +    such as when the upstream branch has local, unpublished commits.
>>>>> +
>>>>> +The base commit must be in a well-known public tree, such as the
>>>>> +subsystem development branch the patch is targeting. See
>>>>> +:ref:`obtain_a_current_source_tree`. Mainline or the latest linux-next
>>>>> +can also be acceptable bases, depending on the subsystem.
>>>>
>>>> I disagree, that's pointlessly too hard requirement.
>>>>
>>>> For many of my contributions base is obvious and not needed to be
>>>> explicitly defined. For all the patches I accept, answer is the same -
>>>> base is either obvious or if not and patch does not apply, then the base
>>>> does not matter.
>>>>
>>>> Requiring it is just bureaucracy without actual benefit.
>>>>
>>>> The only benefit would be if maintainer COULD change its base to apply
>>>> some patch with odd base... but this cannot happen. Maintainer base is
>>>> fixed - it's the HEAD of his development branch for given category of
>>>> commits (e.g. DTS branch for SoC maintainers).
>>>
>>> There are many use cases for applying patches besides the final patch
>>> acceptance, such as review (by anyone, not just a maintainer), testing,
>>> CI systems, etc.
>>>
>>> HEAD of a branch is of course not fixed, and changes every time a patch
>>> gets applied.  That's especially relevant when wanting to check out an
>>> old patch for any reason.  Trying to guess a base commit based on the
>>> date and patch subject is a waste of time.
>>
>> All these tools should just work on top of linux-next. Requiring people
>> to add base like "next-20261021" or "tip-of-obvious-maintainer-tree" is
>> pointless. I understand that base is helping, but helping and requiring
>> an obvious information just do not go together.
>>
>> So again: base has ZERO meaning to the maintainer process. It has
>> meaning to tools, so fix the tools to work on known and obvious trees.
> 
> So what is your proposed algorithm to apply an arbitrary patch when

Already provided that, so to recap:

> there's no base-commit?  Including any historical patch (from
> months/years ago), patches with dependencies, etc.

Dependency is something else, but for every other patch:
1. For testing/CI: you apply on top of next
2. Every other case the maintainer knows where to apply it, because it
is his HEAD of next-branch.

I am repeating myself, but I really had no single problem of lack of
knowledge where to apply a patch as a maintainer or reviewer of some
subsystem, thus maybe I do not understand the actual problem you are
experiencing.

Best regards,
Krzysztof