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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
