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

[Laurent Pinchart]

On Tue, Oct 27, 2026 at 09:10:33AM +0100, Geert Uytterhoeven wrote:
> On Mon, 26 Oct 2026 at 21:12, Rob Herring wrote:
> > On Wed, Oct 21, 2026 at 6:55 AM Krzysztof Kozlowski wrote:
> > > 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.
> >
> > Look at our DT PW. There are numerous patches that don't apply and
> > then we silently don't test them at all. Here's one example[1] (3
> 
> That's a false positive, as the first two patches (the ones that really
> matter for you as DT maintainer) do apply to yesterday's linux-next ;-)
> 
> > actually as the whole series doesn't apply). The more base-commit
> 
> There are indeed patches in that series that cannot be applied, which
> is explained in the cover letter.
> 
> The problem boils down to how to present work that touches multiple
> target trees, and where some parts depend on other work that is
> not yet finished. Do you post it as single series, so people get an
> overview? Do you split it in multiple small series (which may still
> have interdependencies), so everybody looses context?

There's no one-size-fits-them-all solution to this problem. What I want
in those cases is information provided by the person posting the patches
about the dependencies and where to find them. I think there's value in
specifying that information in a machine-parseable way.

> > [1] https://patchwork.kernel.org/project/devicetree/patch/8b2c7719c301a445891fc6c5309456327ec8a94c.1793026273.git.geert+renesas@xxxxxxxxx/

-- 
Regards,

Laurent Pinchart