Cargo fmt should not run on a dirty repository by default

[dhardy]

Problem

1. Hack on code, don't create a commit yet
2. Run cargo fmt; find formatting changes to old code + new code all mixed up

(Yes, I am fully aware that some people frequently do this on purpose. More than once I have received PRs with commits mixing up significant amounts of reformatting and new code.)

Possible Solution(s)
cargo fix, cargo publish etc. refuse to run on a dirty repository by default (but allow override with --allow-dirty). Please do the same for cargo fmt.

The above is only really a problem when significant amounts of old code were not previously formatted, so possibly Cargo+rustfmt could try to detect this first.

An alternative solution might be to make it possible to undo cargo fmt, but I don't see a clean way to do this.

[ehuss]

Would you mind moving this to https://github.com/rust-lang/rustfmt? That's where cargo fmt lives.

Also, I think rust-lang/rustfmt#1324 might be close to what you want. I don't think aborting on a dirty repo is the right behavior, because that's the scenario it runs most often during development (that I've seen).

Some things that can help mitigate the issue:

• Enforce rustfmt on CI. This will ensure everything stays formatted all the time. Changes due to rustfmt versions are rare.
• Run rustfmt from an IDE/editor, where you can rustfmt only a region or single file. This also has the benefit of being easily undoable.

[dhardy]

rust-lang/rustfmt#1324 would help. But your mitigations don't:

• Enforce rustfmt on CI: not everyone wants to do this
• Run rustfmt from an IDE/editor: if your editor does this, then great, my proposal won't inconvenience you. But it doesn't fix my use case at all (which was in fact not intending to format the project but mistakenly calling the wrong command).

[dhardy]

Moved