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

From: Junio C Hamano <junkio@cox.net>
Date: Nov 28, 2006, 00:09 UTC
Message-ID: <7v7ixge8j2.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.63.0611280040480.30004@wbgn013.biozentrum.uni-wuerzburg.de>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 5 quoted lines

> As for reducing the number of lines in the shortlog: taking myself as an 
> example, I often touch the same code several times, just to fix bugs. So, 
> if the same code was touched several times, just take the first oneline, 
> and add "(+fixes)". Of course, this is more like a wedding between 
> shortlog and annotate, and likely to be slow.

Interesting. While driving to work this morning I had the same thought. A revision that does not appear in the output from

	for file in $(list of files the commit touches)
        do
		git blame v2.6.17..v2.6.18 -- $file
	done

can safely be omitted from the shortlog, because later changes fully supersedes it.

I think the list of "important" changes is an interesting problem, but the importance may not directly be related to the number of paths a patch touches (e.g. "you reorder the members of a structure everybody uses in one include file and everything starts performing faster due to better cache behaviour" would be a few lines of a single header file). Also better clues to judge the importance would be found outside the repository. "The patch discussed by many people on the list" and "the patch that had very many iteration to get in the final shape" would certainly be interesting ones, but that information is often not found in the repository.