The docstring for tracked_files is much less informative than untracked_files and will be surfaced in the generated API reference. It would be helpful to document what the paths are relative to, and add a note that the property is expensive/no-cache (similar to untracked_files) so callers don’t accidentally use it in tight loops.

This new public convenience property should have test coverage similar to Repo.untracked_files (see test_repo.py::test_untracked_files). Please add a test that tracked_files returns expected tracked paths (ideally including spaces/unicode), so parsing/quoting regressions are caught.

tracked_files parses git ls-files output by splitting on newlines. This will mis-handle valid pathnames that contain newlines, and can also mis-parse/return quoted or escaped paths when Git applies core.quotepath. Consider calling ls-files with NUL-termination (e.g., -z) and splitting on \0 (dropping the trailing empty entry) to get an unambiguous list of paths.