Linus Torvalds [off-list ref] writes:
On Sun, 26 Nov 2006, Junio C Hamano wrote:
quoted
This implements an experimental "git log-fpc" command that shows
short-log style output sorted by topics.
A "topic" is identified by going through the first-parent
chains; this ignores the fast-forward case, but for a top-level
integrator it often is good enough.
After sending out a response, I re-read your message because I
did not quite get where bayesian would come into the picture.
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.
But again you are showing your superiour intelligence by setting
the problem in a much grander scheme ;-), where there is no such
developer discipline that would help the shortlogger (like use
of topic branches). In such a case, you would need a set of
heuristics that you described.
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).