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

On Tue, Apr 12, 2011 at 2:26 AM, Johan Herland [off-list ref] wrote:

This patch adds an alternative implementation of show_dirstat(), called
show_dirstat_based_on_diffstat(), which uses the more expensive diffstat
analysis (as opposed to --dirstat's own (inexpensive) analysis) to derive
the numbers from which the --dirstat output is computed.

The alternative implementation is controlled by a new config variable called
diff.dirstatBasedOnDiffstat.

So I don't hate the idea, but I do hate the "use a config option"
part. Or rather, I hate the fact that it's the _only_ way to do it
(and the particular config name you chose).

I'd much rather have a command line option for the two cases, and then
have the config file part be a way to perhaps set the default value.

Something like "--dirstat=exact", and then without the explicit
setting you might fall back on the config file.

(One reason I'd like that is that I think the "--cumulative" option
was a mistake. Again, it _should_ have been another option to
"--dirstat", rather than a stand-alone option that makes no sense on
its own)

So in a better world, I think we should be able to write

  --dirstat=[non]exact,[non]cumulative,1

to say exactly what kind of dirstat we actually want. And the config
options would also match, iow

  [dirstat]
     exact = true
     cumulative = true
     percentage = 1

rather than the cumbersome name you chose that is based on an
implementation issue rather than a user interface issue (I think
config options should talk about the user experience more than about
how it was implemented, so "diff.dirstatbasedondiffstat: is not
wonderful)

Wouldn't that be nicer? Can I sucker you into parsing something like that?

If you do this, another thing I've occasionally wanted to see was a
percentage that allows fractional percentages. We show the results in
permille, after all, it should be possible to ask for cut-offs at the
same precision, ie "1.5%".

                 Linus "can I find a sucker to implement this" Torvalds