Add git pre-commit hooks for things like ruff and prettier

[tleonhardt]

I would like to add some git pre-commit hooks for ruff auto-formatting and linting of Python files and prettier formatting of Markdown and YAML files.

Would anyone object to this?

These things are fast and shouldn't slow down work on cmd2. Things that can be slower like mypy and pytest can simply stay part of GitHub Actions CI.

[anselor]

I'm not a fan. It prevents committing your partial progress on a branch

…

On Wed, Jan 15, 2025, 2:00 AM Todd Leonhardt ***@***.***> wrote: I would like to add some git pre-commit hooks for ruff auto-formatting and linting of Python files and prettier formatting of Markdown and YAML files. Would anyone object to this? — Reply to this email directly, view it on GitHub <#1403>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEJC5SRDXXPCY33RJ4WYCJL2KYBQVAVCNFSM6AAAAABVGQV6CWVHI2DSMVQWIX3LMV43ASLTON2WKOZSG44DQOJZGIZTOMI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[tleonhardt]

@anselor What if I limited it just to the auto-formatting and not the linting and configured to automatically do the formatting? That way the worst case you commit the first time, it fixes the formatting and fails the check, you commit again and it works because it was auto-reformatted?

That would give the benefits of enforcing a consistent code style and format without slowing down your ability to commit partial progress on a branch?

[anselor]

I'm torn because, in general, I'm not a fan of tools modifying the code on commit. The whole point of committing is snapshotting your state. If the tool messes up then you've potentially lost your work. While I've not had a problem with ruff doing anything destructive it doesn't mean they couldn't accidentally publish something in the future that is. I'd be more okay if there were a way to perform a validation on commit but also have a way to override the validation if you just want to snapshot your state.

…

On Wed, Jan 15, 2025 at 10:59 AM Todd Leonhardt ***@***.***> wrote: @anselor <https://github.com/anselor> What if I limited it just to the auto-formatting and not the linting and configured to automatically do the formatting? That way the worst case you commit the first time, it fixes the formatting and fails the check, you commit again and it works because it was auto-reformatted? That would give the benefits of enforcing a consistent code style and format without slowing down your ability to commit partial progress on a branch? — Reply to this email directly, view it on GitHub <#1403 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEJC5SW2RBEJR67GNL7JZML2K2AW3AVCNFSM6AAAAABVGQV6CWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKOJTGMYTOMBQGE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[kotfu]

A pre-commit hook is a client-side hook (which means each person has to install/configure it in their local repo). And even if configured you can skip it with git commit --no-verify. I've never used pre-commit hooks that modify the code before committing, but I have created pre-commit hooks that only run on certain branches (so you can have them run on main and develop but skip them elsewhere).

If the objective is to "format my code for me before I commit", @tleonhardt can set up what-ever pre-commit hooks he wants and none of the rest of us have to set them up, or can set ours up to only run on certain branches.

If the objective is to prevent code from being pushed to the github repo that isn't ruff formatted, then we need a pre-receive hook on the github repo which can't change code but which can reject code that isn't properly formatted.

[tleonhardt]

Interesting points @kotfu . @kmvanbrunt Do you have any thoughts on this topic?