Support analysis of tracked files

[spenserblack]

Summary 💡

Converting this comment chain into an issue for discussion/triage: #26 (comment)

Onefetch currently analyzes the filesystem via tokei. However, it seems like some users expect behavior more like github-linguist, which analyzes the language stats of tracked changes (AFAIK it analyzes a rev, defaulting to HEAD).

Utilizing git ls-files can be a partial solution, but it will be buggy:

• Deleted files where the deletion isn't tracked would still show up in git ls-files.
• We'd analyze tracked files, but not the tracked contents of those files, which can be confusing.

We could potentially hack it by stashing changes and restoring them after analysis. But I'm hesitant to have onefetch change the contents of a repository, even temporarily.

Motivation 🔦

There was some initial confusion brought up in #26 (comment), where a large number of untracked files significantly changed the results compared to what the user was expecting.

[spenserblack]

cc @dsully

[spenserblack]

IMO onefetch should do one or the other -- analyze filesystem or git rev. Supporting both would be too complex IMO. So, besides thinking of how this could be done, I think we should ask if this should be done. This would be a significant change and most likely mark a v3 release.

[dsully]

Thanks, I got busy over the weekend.

Agreed on not changing the contents of the repository.

FWIW, my expectation was for onefetch to analyze the tracked files at HEAD.

[o2sh]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.