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

[Geert Uytterhoeven]

Hi Rob,

On Mon, 26 Oct 2026 at 21:12, Rob Herring <robh@xxxxxxxxxx> wrote:
> On Wed, Oct 21, 2026 at 6:55 AM Krzysztof Kozlowski <krzk@xxxxxxxxxx> 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?

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

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds