Re: [RFC/PATCH 5/3] Alternative --dirstat implementation, based on diffstat analysis

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

 



Johan Herland <johan@xxxxxxxxxxx> writes:

> So, how should we count binary files in the diffstat version of
> --dirstat?

IIRC, the reason Linus used the "change" (not "lines") damage computation
in dirstat was exactly for this reason.

Comparing and combining the damage as number of lines and changed bytes
simply does not make much sense, so my gut answer to this question is "we
shouldn't".  The --numstat mode punts exactly for this reason, to avoid
tempting people to add numbers up without thinking and getting nonsense
results.

I suspect that any heuristics is as good as your divide-by-64; you
probably could run count_lines(one->data, one->size) in the text diff
codepath in builtin_diffstat() to keep a running average of the line
lengths of the files involved, but I do not think it is worth it.




--
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]