`treefmt`'s report is confusing

[michaelpj]

Forked from discussion in https://github.com/numtide/treefmt/issues/336.

When treefmt says it matched a file, that means 3495 files matched at least one of the includes globs for a formatter. It then applied those formatters, and afterwards only 51 files had actually changed.

That really isn't how it reads to me, for what it's worth. "formatted" reads like "ran the formatter on" not "ran the formatter on, and changed".

Especially the "formatted X files in Y seconds" line is weird - the time is associated with all the files you ran the formatters on, not the ones that changed!

I would find something like this clearer:

traversed 41932 files
emitted 41932 files for processing
formatted 34771 files (20181 changed) in 24.579394143s

Even better, ditch the first two lines, or demote them to verbose logging. In some circumstances I might be interested in how many files were looked at but not formatted, but not every time!

Or controversially: demote it all to verbose logging. Many formatters work like that, and indeed the information about how many files got changed and how long it took is also readily available from git and time if you want it.

[brianmcgee]

I like having the message emitted each time, but I'll grant you that the phrasing is not clear. There have been a few attempts at getting it right, and I'll admit I like your suggestion.

[zimbatm]

The original idea was to pit the formatters against each other.

Display the timing of the formatters, so the users could see the culprit slowing everything down.

That was the intent. Then over time it slowly morphed into the current design.

[brianmcgee]

🤔 at info level it logs individual formatting times as it applies them to batches.

Could add a summary/ranking output of some form which would be useful to see where it's spending most of it's time.

[zimbatm]

How about:

Summary: SHAME. Formatter X is Y times slower than everyone else

:-D