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