Tally the file formats the candidate corpus modifies, to size the skip notice and prioritize #43

[khatchad]

Two decisions in this repo are waiting on the same unknown, and one pass over the candidate clones settles both.

The Decisions

How discriminating the "not analyzed" list should be. #59 made inspect_commit.py name every modified file it declined to open, so that silence stops standing in for "looked at and found unchanged". It does not discriminate: a README.md lands in that list beside a data.parquet. That was deliberate, because the alternative is a hardcoded notion of which formats count as data and that will be wrong on some repo. It does risk crying wolf, though. Anyone who sees the notice on every second commit because of README edits will stop reading it, which costs more than the ambiguity it was added to remove.

Which formats #43 should take on first. #43 asks for non-CSV files to be handled and names xlsx as its example. Which formats earn the conversion machinery should follow what the corpus actually contains, not which one happened to surface first.

The Measurement

For each of the 374 rows in data/message_refactoring_candidates.csv, collect the extensions of the files that commit modifies.

The extension of a modified file is visible from git show --name-status alone, with no blob read at all, and the clones go under GIT_LFS_SKIP_SMUDGE the way inspect_commit.clone already does them. So no payload comes down. It needs a clone per dataset, which is not free, but it is bounded and it is a one-off.

Deliverable

A script that produces the tally, and a decision on each of the two questions above:

• Whether the "not analyzed" notice needs narrowing, and if so, to what.
• Which format Extend inspect_commit.py to deal with non-csv files #43 should support first.

Report those two conclusions here. The corpus-level distribution itself is a coverage finding for the study rather than an engineering result, so it goes in the research log, not in this thread.

[khatchad]

Partial answer from clones already on disk, enough to settle the first decision.

62 of the candidate datasets were already present in the local clone cache, which resolves 95 of the 374 candidate commits with no new cloning. Numbers themselves are corpus-coverage findings and live in the research log; the engineering conclusions they drive are below.

The "not analyzed" notice does need narrowing

Documentation and notebook files, not data files, dominate the non-CSV modifications in the resolved sample. Markdown alone appears in several times more commits than any unreadable data format. So the notice as it stands will fire on ordinary README edits far more often than on a file whose contents actually matter, which is the crying-wolf failure the issue anticipates.

That argues for narrowing by exclusion rather than by allowlist: keep the notice format-agnostic as designed, but suppress it for a small set of extensions that cannot carry tabular data (.md, .txt, .ipynb, .json, .py, images). A rater who sees the notice should be able to assume it means something.

.xlsx is the right first target for #43

Among formats the tool still cannot read, .xlsx is the only data format appearing in more than one commit in the resolved sample. It is also the example #43 already names. Archives (.tar.gz) appear too, but most archive commits are adds and deletes judgeable as file-level operations without opening them, so the payoff is lower.

Caveat on the sample

The 95 resolved commits are exactly the datasets someone had already cloned, so this is not a random sample of the corpus and plausibly skews toward formats the tool could already analyze. The remaining 279 commits need the full walk before any share is quoted. Both conclusions above are about relative ordering, which is more robust to that bias than any proportion would be.