A useful report answers several small questions together. Language rows show the filename-based composition. Extension rows expose the raw file types behind that label. Byte totals reveal dense or generated text that physical lines can hide. Largest-file rows point to candidates for human inspection. Skip counters explain what the report did not include. None of those tables independently diagnoses architecture or quality.

Language labels are filename-based

SourceTally maps reviewed filenames and final extensions such as Dockerfile, Makefile, .ts, .kt, .py, and .yaml. It does not parse file contents to resolve polyglot templates, notebooks, generated regions, or misleading extensions. Unknown readable files appear as Other text instead of disappearing, so you can inspect the extension table and decide whether a future mapping is justified.

Extension rows expose composition details

One language can own several extensions, and one extension may represent configuration rather than executable source. Compare file count, lines, and bytes together. Many tiny files suggest a different maintenance shape from one huge file. A lock file can dominate lines while remaining useful generated dependency state; its row should inform interpretation, not trigger automatic deletion.

Snapshot bytes are not Git repository size

SourceTally sums included working-tree text bytes. Git storage also contains object compression, prior commits, trees, tags, pack files, refs, and possibly LFS pointers and remote objects. A checkout consumes filesystem allocation and may add installed dependencies or build output. Use dedicated Git tooling when the question concerns clone transfer, object history, hosting quota, or disk usage.

Largest files are starting points, not verdicts

Open a large file in its product context before refactoring. It may be generated, declarative, localized content, a migration, a test fixture, a schema, or a deliberately cohesive module. Review ownership, change frequency, responsibilities, tests, and tooling. The list is valuable because it reduces search space; it cannot determine the correct boundary or whether splitting improves the system.