Closed felixhekhorn closed 1 week ago
That repo is not highly reliable: not updated since 2 years.
If it's working is fine, by we could have to maintain the hooks ourselves, at some point. I'd say that either we find something more maintained, or we directly fork the repository. Such that we are free to modify it, if needed.
I think we would only need to update if cargo
would change, which is highly unlikely - in any case the hooks are very simple so we could even fork and maintain them ...
I think we would only need to update if
cargo
would change, which is highly unlikely - in any case the hooks are very simple so we could even fork and maintain them ...
That's the thing. In any case, I believe we're going to do it soonish, that way is also easier to add more/customize.
I agree that using a git hook is a good idea. Right now we only write what people should do in CONTRIBUTING.md
, with hooks we could automate/enforce it. However, it seems that pre-commit is mostly tailored towards Python and probably a bit too much for what we need; let's talk about that first.
cargo fmt --check
to see if everything is properly formatted.cargo clippy
now, as this returns a very long list of warnings. At some point, however, we might consider doing that.cargo check
? If yes, do we want to run it with --features=applgrid,fktable,fastnlo
or a subset of these (which would require having these libraries installed)?cargo test
, which is a job for our CI.An alternative to pre-commit is writing the hooks manually, putting them into .githooks/
and activating them with git config core.hooksPath .githooks/
.
You are definitely right that pre-commit
is coming from Python ecosystem, but in a sense is only the driver. Could have been written in shell or perl, and it was the same.
The main argument in favor of pre-commit
is that simplifies a set of operations, and provide useful hooks out of the box. The main con is that it is definitely "non-minimal".
The minimal solution would be .githooks/
, but we are adding too much to it, at some we'll start rewriting pre-commit
. At that point the minimality would be defeated by duplication.
How about activating pre-commit here? e.g. this repo provides
fmt
,check
andclippy