Re: [PATCH updated] Add "--dirstat" for some directory statistics

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Feb 12, 2008, 21:56 UTC
Message-ID: <alpine.LFD.1.00.0802121346560.2920@woody.linux-foundation.org>
In-Reply-To: <alpine.LFD.1.00.0802121308360.2920@woody.linux-foundation.org>

On Tue, 12 Feb 2008, Linus Torvalds wrote:

Show 9 quoted lines

> 
> But even for git itself, you can get some fun statistics. Try out
> 
>         git log --dirstat
> 
> and see the occasional mentions of things like Documentation/, git-gui/,
> gitweb/ and gitk-git/. Or try out something like
> 
>         git diff --dirstat v1.5.0..v1.5.4

Side note: this latter one is actually a good example of two different issues.

First off, it's an example of where --cumulative really does make sense, since it reports:

	  10.0% Documentation/
	   4.9% contrib/
	   5.7% git-gui/lib/
	  13.9% git-gui/macosx/
	   8.7% git-gui/po/
	  31.4% git-gui/
	   4.6% gitk-git/
	  13.1% t/

ie it makes it clear that almost a third of changes between 1.5.0 and 1.5.4 was in git-gui/.

But secondly, it's an example of how the whole --dirstat is totally buggered in certain circumstances, because the above is simply not *true*: yes, a lot of the changes were actually due to git-gui, and all those *.po files, but the git-gui/macosx/ count is ridiculously off.

Why? That directory has a binary file, which doesn't have a "line count", so --dirstat actually ends up using the byte-count instead there, which inflates the macosx numbers a lot (same is true of git-gui/lib/, just to a smaller degree).

I don't think that's necessarily a bug, but it's certainly misleading. Does it matter? Not to me, because the kernel generally doesn't have those kinds of issues (no binary blobs that ever really change), but I did want to point out that there's room for perhaps improving things. Maybe we could add a byte count in general to the diffstat data structures and always just count bytes changed rather than lines changed. Or maybe we should consider binary files to have something like "32 bytes per virtual line" or something.

So _I_ don't care, but if somebody does, maybe they want to do something about it. I thought I'd point it out since I just noticed.

					Linus