New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
Automatically apply changes and retry or only run if previous hooks succeeded #1817
Comments
I tried search for relevant tickets, but couldn't find any. I'll read these, thanks! |
@MarcoGorelli thanks again for the quick response. Definitely understand about not wanting to stage things automatically. Just one final follow up question if you don't mind: What do you think about preventing hooks from running instead? If I could tell mypy, flake8, and other static checkers to skip running if a previous hook had failed, that would also be very nice. Has this also been asked 100x? 馃槄 If so, apologies, I wasn't able to find anything in the issue tracker |
yes that's the |
Thanks 馃憦馃憦馃憦馃憦 EDIT: I guess what I was after was a hook-level fail-fast option, but I discovered a new setting I didn't know about that solves the same issue: I've specified mypy to run on push instead of commit 馃帀 |
Hi,
First of all thanks for the awesome framework. Pre-commit is great 馃憦
I often find myself running pre-commit by adding my changes with
git add
and then committing. Then, typically it will "fail" because just one or two lines will be fixed by one of the hooks (typicallyblack
), and I will re-run the git commands once more to finish committing my changes.This doesn't take much effort, but running everything twice it is a pattern I repeat almost every time I commit something: Would you ever consider adding an option to automatically re-committing the changes made by individual hooks? As in, say you could specify in the config that if
black
makes changes, pre-commit should simply add those changes to the staged diff, before running the hook once more, and then running the remaining hooks?To prevent the xy problem: the underlying reason why running pre-commit twice can sometimes be inconvenient in the first place, is because we have several static checkers like
flake8
andmypy
which we don't really want to run until all code changes are out of the way. Ourmypy
hook in particular can take up to 10-15 seconds to run, and as a consequence I will usually interrupt pre-commit after the first few hooks have run (if one "failed") and re-run all commands.Finally, I recognise that there might be good reasons why this doesn't make sense; that pre-commit could be built in a way where it's not worth a complete restructuring to implement such a feature; or that perhaps my workflow is just sub-optimal, so this is primarily a question over a feature request 馃檪
Thanks!
The text was updated successfully, but these errors were encountered: