Re: [PATCH] (experimental) per-topic shortlog.

From: Linus Torvalds <torvalds@osdl.org>
Date: Nov 27, 2006, 01:53 UTC
Message-ID: <Pine.LNX.4.64.0611261747380.30076@woody.osdl.org>
In-Reply-To: <7vejrpr7mw.fsf@assigned-by-dhcp.cox.net>

On Sun, 26 Nov 2006, Junio C Hamano wrote:

Show 6 quoted lines

> 
>  - a two-commit series on MIPS via Ralf Baechle,
>  - a four-commit series on ARM via Russel King,
>  - a three-commit series on POWERPC via Paul Mackerras,
>  - a seventeen-commit series in net/ area via Dave Miller,
>  - a three-commit series on x86_64 via Andi Kleen.

You'll reasonably often see in the kernel:

 - a patch-series by Andrew (where nothing but filename clustering really 
   would help: the committer is me, and the thing is linear)

 - linearly on top of that, a git merge that was a fast-forward 
   (especially from the subset of people who actively rebase their trees: 
   that notably includes Dave Miller, but also for example the DVB people)

so purely a first-parent logic would not catch that case at all (but the committer would at least catch the "patch-series by Andrew" -> "Merge of network tree by Davem" break).

But especially with long patch-series through Andrew, it would be nice to have some other heuristics (although they _tend_ to be fairly random, especially at the end of the release cycle - at the beginning, I tend to have series of 100-200 patches that often _could_ be clearly clustered into a few clusters).

Anyway, the real win of clusterign would likely be for big releases, ie soemthing like "v2.6.18..v2.6.19-rc1", where there's definitely some clustering even apart from just merging (although the merge topology will definitely get some of it)