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

[Eric Biggers <ebiggers@kernel.org>]

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

- Eric