Re: [MAINTAINERS SUMMIT] Hidden commits from next (aka why maintainers hoard them in backpack)

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

Hi Steve,

On Thu, Sep 11, 2025 at 10:25:06AM -0400, Steven Rostedt wrote:
> On Thu, 11 Sep 2025 14:40:45 +0100 Mark Brown wrote:
> 
> > > I've heard a maintainer saying that Linus doesn't like subsystem trees
> > > to have lots of merges. Any help debunking that would be appreciated.  
> > 
> > AIUI it's a quality of merges issue rather than a number of merges
> > issue, if the merge commits all have commit messages that convey useful
> > information about something that makes sense then you should be fine.
> > If the merge commits are all just default messages not so much.  Things
> > like taking a pull request with a descriptive commit like the cover
> > letter for the merge hopefully do have some purpose and a useful commit
> > message.  
> > 
> > The quantity thing comes up because a common way you end up with a lot
> > of merges is automation which tends to also imply lacking changelogs and
> > motivation.
> 
> Basically a merge commit should be no different than any other commit. It
> should have a purpose and that purpose should be described in the merge's
> change log just like every other commit has its purpose described in their
> own.
> 
> I now have several topic branches, and I try hard to avoid merges as they
> tend to make my pull requests more complex. But every so often, I have a
> patch that comes in that is required for work in two of my existing topic
> branches. This is a case where one change is required for two topic
> branches to continue more work.

Do you then send an individual pull request for each topic branch to
Linus ?

What if one of those topic branches had to aggregate patches from, let's
say, 10 different series from 10 contributors who each sent you a pull
request ? Would you merge them or cherry-pick them ?

> In these rare events, I will apply the change to one of the topic branches,
> then merge it into the other with a detailed explanation to why I needed to
> do that merge.
> 
> Linus hasn't complained about it, so I'm guessing that's the correct thing
> to do.

-- 
Regards,

Laurent Pinchart