What about adding a git hook?

Please remove the 22-file format-only commit from this PR.

@apoelstra I've rebased and removed that commit. Though I don't really understand the intention, at some point that diff is going to be added. If not in 1 big bang then step by step as ppl edit files and format them or?

It can be added when/if rustfmt ever stabilizes.

My understanding at the beginning of this thread was that an empty rustfmt file would tell auto-rustfmt tools to not enforce any rules. Is that correct?

Empty rustfmt file would tell auto-rustfmt tools to use default formatting settings, and possibly encourage using these tools.

I believe that it would be better to turn off all rules, and, over time, explicitly add rules as we agree on which ones are needed.

What is there to agree on? Rust has a defined standard formatting style.

Frankly, I think it was a mistake to even have any configuration for rustfmt. Rust has a chance to be a language in which all the code out there has at least uniform look: everyone can just get used to it. Now rustfmt being so configurable opens the door for C++ madness to slowly creep into Rust ecosystem, where everyone has their own opinion where do closing parenthesis go, and some projects use tabs and some spaces, camel case, etc. because "screw everyone, it's my project, and I like mine settings better than some stupid standard". rustfmt having configuration options for style is just additional work and complexity for the whole purpose of people be able to screw everybody else.

I eg. prefer tabs over spaces, but what's decided is decided, I have my editor set to spaces in *.rs and I format all my projects with plain rustfmt and I worry about real problems, and not trivialities like the way rustfmt broke lines of my code exactly. But dev community is just a bunch of disagreeable people, and they will never agree on anything, especially if it's trivial and actually insignificant, so I guess soon I will have to be switching tabs and spaces between Rust projects too.

They seem to have released version 1.0.0 recently. I don't know how stable it actually is, but they write that only macros and some other obscure cases will be unstable.

If wanted to use rustfmt I'd argue for a big-bang transition (even though it messes up git blame) and CI enforced formatting afterwards. For that to work we should define a fixed version of rustfmt to use for rust-bitcoin (the organization) and only change it when absolutely necessary. That would solve most of the instability issues (just not using new rustfmt versions). And some noise in form of a formatting PR every one or two years maybe doesn't sound too bad to me.

If we don't want rustfmt yet because of possible instabilities I'd like to close this PR (it doesn't do much anyway) and use #172 to track the stabilization progress of rustfmt instead.

I think it's fine to do a big-bang transition with rustfmt 1.0.0.

@bodymindarts would you like to redo this PR with rustfmt 1.0? Or should one of us take that on?

Closing due to inactivity. Leaving the issue #172 open.