Investigate usage of git pre-commit hooks

[boxtown]

It would be nice to have pre-commit hooks that run rustfmt, clippy, and tests. Need to do research into a smooth workflow

[paulkernfeld]

Is this still of interest to you? I have had success defining a build process using cargo-make. The build steps are defined in a file called Makefile.toml (example), and you would set up a git pre-commit hook that looked something like cargo make all.

If cargo-make doesn't seem like a good solution, this could also be done using a Bash script, but that wouldn't be as portable to platforms like Windows.

[boxtown]

Yeah looks interesting. If you'd be interested in drawing something up I'd definitely take a look at it

[dhardy]

Sorry to interject now, but I question the wisdom of using pre-commit hooks. If you wish all submissions to be rustfmt- and clippy-clean, then you may state that in your contributing guide (you do already for the first) and even enable CI testing if you wish (I have found this a nuisance in the past but it's viable).

Running these automatically during pre-commit could impact workflow negatively given that rustfmt actively adjusts code (I have had it prevent code from compiling before). Using a pre-receive hook may make more sense (see https://githooks.com/).

(Personally I don't find it useful to enforce code style rules unless, very rarely, I get a PR with ugly code. I also do not consider many of Clippy's suggestions useful. Largely this stuff is just a matter of taste.)

I'm not sure that @paulkernfeld's solution will help much given that many users are used to typing cargo test and cargo fmt? It is simply another way of achieving the same thing.

[boxtown]

It's interesting that rustfmt can break your code, that doesn't seem like something that should happen. I mostly opened this issue because it's hard to tell in a PR whether or not rustfmt has been run, particularly with white-spacing. This then becomes a slight nuisance later on when I or someone else edits a file that sneaked in without formatting, and our PRs become bloated with formatting changes.

I'm going to play around with @paulkernfeld branch and cargo make for a little but I'm also open to other suggestions to resolve the above issue

[dhardy]

It's interesting that rustfmt can break your code, that doesn't seem like something that should happen.

They've probably fixed it by now; it was a corner-case involving a range (..) and other op.

I tried running rustfmt on the Rand project this week; nothing broke but I decided the result was in many cases worse than the current formatting (in my opinion).

[boxtown]

I'm personally less interested in the formatting than just having it be consistent for everyone who contributes. We can always customize the formatting through the TOML file