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

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

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

Show 5 quoted lines

> 
> 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).