In terms of behaviour, would you expect treefmt ./some/gitignored-file to format or ignore the file?
I think a more idiomatic way would be to have an "internal/walker" package.
Yeah that's great, I think it's going to make the project so much nicer
If it's following git ls-files then I would not process the .gitignore files. If the user wants to ignore something, they can still ignore them by adding them to the global excludes list.
The phrasing is a bit ambiguous. Maybe "Don't respect .gitignore files"?
The rust ignore crate is a bit weird; it also loads .ignore files and generally doesn't traverse any files starting with a .. That has caused a few issues already. Eg: the latest: https://github.com/numtide/treefmt-nix/pull/146
Personal taste thing: because of how many public/private fields there are, I would split this into a FormatterConfig that only contains the config and serializes/deserializes, and then the Formatter that gets generated from the config. That way, how to interact with the structs in the rest of the code becomes clearer. I don't think the Before field should be mutated in the code for example.
I haven't wrapped my head around the concurrent aspect of the code, but the rest looks good.