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

[Linus Torvalds <torvalds@osdl.org>]

On Sun, 26 Nov 2006, Junio C Hamano wrote:
> 
> I think I should have used the word "topic branch" instead of
> "topic".  In other words, I was not interested in sifting the
> various totally unrelated linear commits into groups that deal
> with distinct problems.

Well, I think you're grown slightly jaded by the fact that git has very 
active "normal" development, that is actually done by you on the main 
branch, and you do basically zero rebasing along the side branches.

I think that's actually likely the exception rather than the rule. It's 
much more likely that people have almost _all_ active development done on 
side branches, and that - together with rebasing of the side branches - 
inevitably means that the "main branch" ends up not having such a clean 
set of "topic branch" merges.

In addition, on a more mature tree, a lot (probably _most_) of the commits 
aren't really "topics" at all, but "maintenance", which exacerbates the 
problem: you don't have a "line of development of this feature", you tend 
to have much more of a random "fix this general area", where the only 
common theme may be the fact that things are _related_ to some common 
subsystem, but not that they are a "topic branch" in the _development_ 
sense.

Put another way: bugs get fixed one by one, not in a nice linear fashion 
by "topic".

So I'm coming at it from a totally different project - where "topic 
branches" simply aren't delineated as much, and even when they are, they 
tend to be merged in multiple steps (and they pull both ways when they 
aren't re-based).

So that's why I don't think the pure branch topology is as interesting. A 
single line of development ends up being useful for you, and we'll 
certainly see _some_ of that, but in the kernel, I pretty much guarantee 
that you probably get better "topic clustering" by going simply by author, 
like the old standard "git shortlog" does. Because that will tend to get 
the clustering at a finer granularity (ie not just "networking", but 
things like "packet filtering" etc).

So the "sort by people" actually works fairly well, but it's kind of an 
"incidental" thing, and it _would_ be potentially useful to have other 
ways of grouping things.

See? It's not about "superior intelligence", it's about simply a totally 
different development phase (and a less strictly defined problem space).