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

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

On Wed, Oct 21, 2026 at 01:55:37PM +0200, 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.

When I review patches, I often need to apply them to a tree, mainly to
see the context, but sometimes also to test them. I have encountered
many cases where the patch wouldn't apply on the current for-next branch
of the relevant subsystem. That's often because the patch had
dependencies. When I'm lucky they are listed manually in the cover
letter with a link to a branch, but that's far from being the common
case. I then have to ask the submitter to provide a branch, or enough
information to recreate a branch. Having base information (base-commit,
prerequisite-patch-id, and possibly base-tree) would save me quite some
time.

I understand your concern about maintainers cherry-picking and sometimes
introducing issues as a result. In that case I also prefer asking the
submitter to rebase, retest, and resubmit. That's not what I want to use
base information for, in my case it helps with the review process.

-- 
Regards,

Laurent Pinchart