Am I clear enough? I haven't had much sleep recently…
@Hecate Honestly, no. But maybe you had time to catch up on sleep?
I haven't set it up as a pre-commit hook yet as I don't fully understand it, but running it manually before a commit does only complain about unclean working state.
But the important thing here is that since it returns 1 as an exit code, it will abort the commit step and let you apply
stylish-haskellon the incriminated files.
Do you mean that I then manually shall invoke stylish-haskell -i on each Haskell file in the repo?
Couldn't I just let the pre-commit script make that do automatically, or are there edge cases where stylish messes up the not-yet-commited changes (e.g. syntax errors, incomplete implementations)?
The helper script can be run in a CI action or a pre-commit git hook (very useful, I also use that for hlint).
If run as a pre-commit hook, wouldn't it always complain about a dirty working directory then as before a commit changes aren't commited yet?
And finally, a stylish-haskell helper script that detects if code files are dirty. Can be useful for CI, although manually calling it can be nice if you would rather first implement then beautify.
@hecate I do not fully understand what's the best way of using stylish-haskell in my workflow:
On the one hand I'm too lazy for calling the tool itself for each single file of my project.
When using the helper script, I usually commit my changes first, then run the heloer script and --amend the formatting changes to the previous commit. This only works though when always committing all changes from the repo, not only those of a single file or even a chosen patch set.
Why does the helper script care about a dirty working directory?