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

[Linus Torvalds <torvalds@osdl.org>]

On Sun, 26 Nov 2006, Junio C Hamano wrote:
> 
>  - 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)