Jeremy Fleischman

I am not supportive of this, as I would prefer people strive to keep their individual repos "self contained". See https://github.com/numtide/treefmt/issues/619 for a related discussion.

Is it worth discussing how to make parallel usage of treefmt work better? A couple ideas: 1. I see that bbolt has a sharable, read-only mode: https://github.com/etcd-io/bbolt?tab=readme-ov-file#read-only-mode. We could rework...

> But it seems passing the CLI argument results in ignoring other configuration sources? IIUC, this sounds like a bug. Can you file a separate issue for this with more...

> I'd like to have the wrapper but also configure exclusions per project. It sounds to me that you have a globally installed treefmt? That is not something I would...

> But, I have a lot of small repos, so it's not feasible to update everything I still don't get it. Where does your `treefmt.withConfig` code live? How do other...

This sounds problematic to me. Imagine you upgrade this central repo to use a newer version of some formatter, or to start enforcing formatting for some filetype that previously didn't...

> I'm wondering if it might be better to allow passing through git args? Coupling ourselves to the git cli smells wrong to me. We used to use a pure-go...

That's fair. I personally am not anxious about being coupled to the git cli, either, but I do think it's worth acknowledging that it's different than just being coupled with...

Looking through `git ls-files --help`, I see that some of these flags affect the formatting of the output. For example, see `-z`: > ``` > -z > \0 line termination...

Oooh that's a neat idea, as it would allow people to use non-git vcs tools.