John Paton

This is correct and the intended behaviour. `pre-commit` themselves promise to never modify the staging area - the user needs to take responsibility for any code changes that are being...

Agreed, I admit once I trust a hook I commit its output pretty uncritically - but at the end of the day it's still my name on the commit.

> there is a need to version notebooks > > I want to be able to edit exclusively the .ipynb files This is a good use case for the existing...

Only if there are also conflicts on the `py` files (in the case of code changes), in which case they need to be resolved anyway, or in case people commit...

Hey, just a comment here: having to re-`add` and re-`commit` the files after the pre-commit hook runs is a feature, not a bug. See discussions e.g. [here](https://github.com/pre-commit/pre-commit/issues/806) and the issues...

You could automate a new PR with the changes, and then all they would have to do is take a quick look (if they want) and merge? It's still kind...

I can't comment on the behaviour of any git GUI since I don't use them, sorry! But at least for the [pre-commit framework](https://pre-commit.com/) this workflow of try to commit ->...

In principle `pre-commit` only acts on files that are staged, or on all tracked files if you use `--all-files`. If you want something like this I think your best bet...

Auto-syncing on save is certainly possible via the Jupyter UI, @mwouts can tell you how to configure :) Not sure about other editors

Just putting commands in your git `hooks/pre-commit` also works of course, that's just not the same as using the `pre-commit` framework which has its own set of features but also...