Message-ID: <CAHk-=wiGymybvnQu2=+nzc18HkRudoeJODci13RBDr5afyDjfg@mail.gmail.com>
Date: Sat, 16 Mar 2024 13:42:06 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Borislav Petkov <bp@...en8.de>
Cc: Steven Rostedt <rostedt@...dmis.org>, LKML <linux-kernel@...r.kernel.org>, 
	Masami Hiramatsu <mhiramat@...nel.org>, Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, 
	Beau Belgrave <beaub@...ux.microsoft.com>, Chengming Zhou <zhouchengming@...edance.com>, 
	Huang Yiwei <quic_hyiwei@...cinc.com>, John Garry <john.g.garry@...cle.com>, 
	Randy Dunlap <rdunlap@...radead.org>, Thorsten Blum <thorsten.blum@...lux.com>, 
	Vincent Donnefort <vdonnefort@...gle.com>, linke li <lilinke99@...com>, 
	Daniel Bristot de Oliveira <bristot@...hat.com>, x86-ml <x86@...nel.org>
Subject: Re: [GIT PULL] tracing: Updates for v6.9

On Sat, 16 Mar 2024 at 13:00, Borislav Petkov <bp@...en8.de> wrote:
>
> On Sat, Mar 16, 2024 at 11:42:42AM -0700, Linus Torvalds wrote:
> > Now, I'm not suggesting anything like the multiple topic branches from
> > -tip (from a quick check, there's been a total of 25 tip/tip topic
> > branches merged just this merge window), but for clear new features
> > definitely.
>
> So some of those branches are really tiny (1-2 patches) during some
> cycles so I have often wondered whether I should merge those small
> branches into a single pull...
>
> So as not to have too many tiny pull requests.
>
> Any preference?

Not really any strong preferences.

The really tiny ones are so easy to pull that pulling a few random
ones just isn't an issue.

I've been known to occasionally end up doing an octopus merge if I
decide that I might as well just merge multiple small branches in one
go, but honestly, I stopped doing that because it's just simpler to do
two really trivial merges than to even bother thinking about "should I
just merge these all together".

So I don't mind getting three or more random small pulls if they all
still make sense (ie they are clearly separate things).

Now, if you send me three separate pulls for basically the same
conceptual thing, that might annoy me just because it would be so
pointless.

But if it's a "one pull to fix a single-line issue in resource
control, and another pull to fix a single-line issue in objtool", then
those make perfect sense to keep separate, even if they are both
trivial and small.

And on the other hand, if you have a couple of trivial branches with
no real pattern, and decide to just merge them into one that fixes
"misc x86 problems", and the end result is still completely trivial
and there are no surprises or gotchas, that's not wrong either.

And sometimes, merging and sending me just one pull request is
absolutely the right thing.

For example, the ARM SoC trees tend to just merge "umbrella" updates
into one single pull request, and I prefer that - because I see no
point in getting ten different "this is the drivers for SoC xyz"
thing.

So then it's still a clear topic branch ("ARM SoC drivers"), but they
kept multiple branches for different SoC's and sent me just one pull
request.

End result: there's no one right thing.  Make it make sense. Probably
the only real rule is

 - try to keep conceptually different things separate just for cleanliness

 - definitely keep fundamental new features or anything that _might_
be questionable in a branch of its own

but there aren't some kind of black-and-white rules for "this is so
small that it's not worth sending on its own".

This merge window, I think I currently have something like ~15 merges
that ended up being literally just a couple of lines (maybe spread
over two or three files). I don't mind at all. If that's all that
happened, that's fine.

               Linus

Powered by blists - more mailing lists