Danny Hooper

Not really. I'm trying to implement `track` by refactoring `GitIgnoreFile` into a trait to allow it to interact with an impl that uses a `Matcher`, so I can just construct...

My expectation is that users will generally run `jj fix` without arguments, relying on a configuration of multiple tools that they rarely interact with, and that multiple invocations for different...

Here's a concrete proposal for the configuration syntax. A simple example for a single code formatter: ``` [[fix.clang-format]] command = ["/usr/bin/clang-format", "-", "--assume-filename=$path"] patterns = ["**.cc", "**.h"] ``` This would...

This happened a while back in https://github.com/martinvonz/jj/pull/4079.

https://github.com/martinvonz/jj/pull/3857 addressed the issue of fixing a subset of changed files. There's still some room to determine exactly how fixing unchanged files should work. Some possibilities: - All patterns always...

I tried to describe that in the "alternatives" above. I don't think it's practical, but I would love to see any evidence to the contrary. I think the main pitfall...

I'm partial to the run/fix distinction being equivalent to the per-working-copy/per-file distinction, but mostly due to familiarity with such an implementation for `hg`. I wonder if there are other granularities...

To be clear, the main reason `jj fix` exists right now is because it is immediately valuable to Google, even in its nascent form. That `jj run` isn't fleshed out...

That last point about "seeing changes made in previous commits" is important. It could either be considered as another dimension, or part of the "scope" dimension from my last comment....