Pre commit hook workflow

I’m trying to set up a pre-commit hook workflow following the docs but having some issues with what I have in mind. The workflow I’m immagining right now is as follows:

1. Make changes to notebook
2. add notebook to staging area
3. commit => before committing the pre-commit hook runs converts the notebook to .py adds it to the commit and then proceeds to committing

From reading the issue where support for the pre-commit framework was added, it looks like that the problem is in the last point: the pre-commit hook is supposed to generate the .py file but not add it to the staging area.

My issue with this behaviour is that this way I always have to make tha same commit twice, once for the notebook, once for the .py. Indeed, if I’m working on the notebook file and not touching the .py, from one commit to the next the .py is going to be the same so git won’t event let me add it to the staging area. Then, when committing the first time around, the jupytext pre-commit hook fails telling me that the git index is outdated and asking me to add the .py to the staging area; then running the commit a second time adding the generated .py everything works fine.

My question is, is this the intended behaviour or am I missing something?

[JohnPaton]

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 different outputs. If you’re worried about that you could use something like kynan/nbstripout to additionally remove the outputs, and then there can only be conflicts in both files or neither, since the content will be essentially the same.

[JohnPaton]

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 committed, essentially. See for example this issue