Re: [MAINTAINERS SUMMIT] Any feedback for -next?

Hello Mark,

On Tue, Aug 11, 2026 at 05:54:59PM +0100, Mark Brown wrote:
> Any other ideas?

One thing I recently wondered is if it would make sense to not merge one
tree after another into the same tree, but first create pairs, then
merge two pairs, ...

So the resulting history doesn't look like:

*   4c0d3bb911f5 Merge branch 'E' into HEAD
|\
| * 43c281fce114 E
* |   13879e35a4ac Merge branch 'D' into HEAD
|\ \
| * | fc44516d50b1 D
| |/
* |   7264b63a7026 Merge branch 'C' into HEAD
|\ \
| * | 16f2802060cb C
| |/
* |   5928d0287cf0 Merge branch 'B' into HEAD
|\ \
| * | 793fdef4e4e3 B
| |/
|/
* 1e7199adfd77 base

but:

*   53dad0ca9b44 (HEAD) Merge branch 'B+C' into 'D+E'
|\
| *   54d327c589e7 Merge branch 'E' into 'D'
| |\
| | * 43c281fce114 E
| * | fc44516d50b1 D
| |/
* |   e75826f69561 Merge branch 'C' into 'B'
|\ \
| * | 16f2802060cb C
| |/
* / 793fdef4e4e3 B
|/
* 1e7199adfd77 base

.

The advantage is that if commit B breaks something there are less
intermediate trees that don't contain B and you can still test on e.g.
D+E.

I'm not convinced the advantages outweight the additional effort, but
IMHO this is a bit similar to the request by the filesystem guys to have
a tree with only filesystem changes.

So this is just an idea that might be worth to be thought about by more
than just me.

Best regards
Uwe

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEEP4GsaTp6HlmJrf7Tj4D7WH0S/k4FAmp8VqYACgkQj4D7WH0S
/k74rQf/XATSq0OIpLM9cJzDG+3OZ012nb5lNjJ/DnvWKWXHIaoS/pZGOvtoFWtE
h1SgImA5a334T0E0xoWIkHP1hDDoCRPrWm2R9ZBA4AV4uGg0TDJEPIL6wybfs+kg
ShLAHKdg3ul2CwJ09vF/qiRwR/UnQh3tWdfz+C60a/HU9fAtRy2oObu3J8O8aXIK
yKFsbi6JvAImAa1xfWFVR8Io1OlFr5o3YHrkVfERNHZIsGnOGOKptwWgUa+gCD1+
AOzlHNdTx+Jk7y9GIqDcD3sZyOQ/JK9DVWcv/qPd5uy0PmxnEBTTyywOyNpxeKHZ
YoxohZNYZb6dk1ky4ax1NUlVZAsCJQ==
=FZxn
-----END PGP SIGNATURE-----