Message-ID: <b5cb2b64-483c-4c38-b7ff-de045a420ef4@paulmck-laptop>
Date: Wed, 30 Jul 2025 15:59:43 -0700
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Neeraj Upadhyay <Neeraj.Upadhyay@...nel.org>, joelagnelf@...dia.com,
	frederic@...nel.org, boqun.feng@...il.com, urezki@...il.com,
	qiang.zhang1211@...il.com, linux-kernel@...r.kernel.org,
	kernel-team@...a.com, rcu@...r.kernel.org, Tze-nan.Wu@...iatek.com,
	a.sadovnikov@...ras.ru
Subject: Re: [GIT PULL] RCU changes for v6.17

On Wed, Jul 30, 2025 at 03:34:55PM -0700, Linus Torvalds wrote:
> On Wed, 30 Jul 2025 at 12:24, Paul E. McKenney <paulmck@...nel.org> wrote:
> >
> > As it happens, I will be sending the pull request for the v6.18 merge
> > window, so I will stop doing my usual octopus merges (hey, they *were*
> > cool!) and instead merge each branch separately, with each merge's commit
> > log giving a synopsis of the commits in the branch being merged.
> 
> Note that octopus merges aren't a no-no per se. Sometimes they make
> perfect sense, particularly if there's a handful of really trivial
> branches with just a commit or two each.
> 
> Then an octopus merge can be a really convenient way to avoid having
> as many merges as you have "real" commits.
> 
> So don't take my comment as a "never use octopus merges".
> 
> Take it more as "octopus merges have some downsides, and making _any_
> merge without an explanation for it in the commit message is bad".
> 
> The main downside of octopus merges really is just bisectability:
> because even if the problem doesn't end up being the merge itself, an
> octopus merge can make it fundamentally hard to do the "cut the
> history in two roughly equal points for testing".
> 
> But again, that's not a problem if you have just a fairly small
> handful of purely trivial commits.
> 
> So people just need to balance the "octopus merges are cool, and can
> avoid pointless repeated silly small merges" with "octopus merges can
> make for bisectability issues and should be avoided for anything even
> halfway comples".
> 
> (Also, try *very* hard to avoid octopus merges when any conflicts
> exist - even trivial ones. Octopus merges with conflict resolution
> take "that's hard to follow" to a whole other level, to the point
> where you really shouldn't even try).

Thank you!

So octopus merges of documentation, torture testing, and other things that
are very unlikely to matter for bisection should be fine.  Branches that
are not going to interact should be fine, give or take any uncertainty in
"not going to interact".  No merge conflicts are permitted in octopus
merges.

On the other hand, given that there are cases where octopus merges are
not fine, it might be more straightforward to merge one branch at a time.
The main loss is that remerging after applying fises is a bit easier
with octopus merges, but that isn't a big deal.

So it might be time to say "goodbye" to octopus merges.  I will try
that for v6.18.

> > If you have a best-practice series of merges example in mind, could you
> > please point me at it?
> 
> It's hard to give a good "typical" example, because I don't think
> "typical" exists.
> 
> Sometimes a simple one-line merge message just stating "Misc fixes for
> subsystem Xyz" really might be the "proper" merge message.
> 
> Because maybe that branch really had all just tiny uninteresting
> fixes, and git shortlog entirely describes it all to the point that
> writing anything more would just be wasting everybody's time.
> 
> Honestly, the merge messages you guys send me for *my* RCU merge are
> fine - the only thing I ask for is that instead of describing the
> branches with an esoteric branch name, you write them out for humans.
> 
> So having the header read "Improvements expedited RCU grace periods"
> or something is just _soo_ much more understandable than
> "rcu-exp.23.07.2025", wouldn't you agree?

Fair point!

> As to the merge messages for *your* own merges, where you just put
> several branches together in order to send the result to me: knowing
> that there will be a more complete message in the upstream merge, I
> think the main issue is to think about people who hit that merge
> because they have some issue.
> 
> So again, it might be because somebody ends up hitting that merge
> during bisection, or has some other reason why they are looking at
> that merge in particular, rather than the "bigger picture" upstream
> merge.

And that argues for putting the material that we currently put into the
pull request into the merge commit logs.

> In other words, please write merge messages with the intended audience
> in mind. They don't necessarily need to be the same kind of
> full-fledged explanation that I want to explain why I'm merging (and
> for people who follow the development process: people most definitely
> look at the pull requests that come upstream, and it's informative to
> not just me, but you find tech press etc looking at them too).
> 
> But you should at a minimum think about "what if somebody hits this
> during a bisection". Give those random developers a clue about what is
> going on. Don't just make it be that "Merge branch XYZ", because that
> tells _outsiders_ so little.
> 
> Does that make sense as an answer?

Very much so, and again thank you.

> Anyway, I'm happy to say that if you are looking for _examples_ of
> merges, we have tons of them. I'm proud of the fact that I think
> kernel commit messages in general are very good, and when I compare
> them to other projects I feel like we tend to do a stellar job. And
> I'm not just patting myself on the back, we have tons of good
> examples.
> 
> So you can do a
> 
>     git log --merges
> 
> in general, and while you'll find some that just list branches, I
> think most of them tend to be very good these days. Look at the
> networking and bpf merges, for example (so typically Jakub and
> Alexei). Or the SoC merges (Arnd), or the VFS merges (Christian
> Brauner).
> 
> Or really most of them. I started looking for more names (the ones I
> mentioned were people I already knew wrote good merge messages), and
> really my reaction was that "most of them are great".
> 
> Good on us.

Thank you, and as you say, lots of examples.  ;-)

							Thanx, Paul

Powered by blists - more mailing lists