Re: BUG? in --dirstat when rearranging lines in a file

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes:

> That said, honestly, for dirstat, the big issue was that it made it
> really really simple. Look at how small the dirstat patch was (commit
> 7df7c019c2a4), and realize that it's because it just re-used the
> existing damage counting code.

Yes, the most of the logic added by the patch is to percolate the damage
point up the tree to either coalesce or filter the result into manageable
size.

Speaking of that logic, I've been wondering for about a year and a half if
this "if (permille)" exclusion was intentional:

	/*
	 * We don't report dirstat's for
	 *  - the top level
	 *  - or cases where everything came from a single directory
	 *    under this directory (sources == 1).
	 */
	if (baselen && sources != 1) {
		int permille = this_dir * 1000 / changed;
		if (permille) {
			int percent = permille / 10;
			if (percent >= dir->percent) {
				fprintf(opt->file, "%s%4d.%01d%% %.*s\n", line_prefix,
					percent, permille % 10, baselen, base);
				if (!dir->cumulative)
					return 0;
			}
		}
	}

If the user sets dir->percent to zero, with an expectation that it will
disable all filtering, shouldn't we show everything?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]