feature request: mode to exit 0 if only autofixes were triggered

[ryanrhee]

i did a quick search on existing issues but didn't find one that matched what I want. apologies if this is a duplicate.

---

sometimes i find myself running pre-commit run -a twice, usually in a script. this most recently happened when i needed to run all my linters as a part of a script. (exact details are described in this issue lerna/lerna#1415 (comment) ; basically, using lerna to publish a package to npm involves editing a json file and committing the change, and i need to configure a script to run prettier via pre-commit before this commit happens.)

my first try was to run pre-commit run -a && ... && git add .... it did reformat the json file as I wanted, but then the script invocation failed because the call to pre-commit exited with a non-zero code. the fix was to change the script invocation to pre-commit run -a; pre-commit run -a && ... && git add .... this makes it to where the first invocation of pre-commit can return any code; assuming that only autofixes were applied, the second invocation should succeed.

i think that when running pre-commit as a generalized lint-runner, the desired behavior changes to the following:

• if everything is green, exit 0
• if things were autofixed, but otherwise everything is ok, still exit 0
• if something is broken and/or not autofix-able, exit nonzero

my feature request is for pre-commit to provide this behavior as a flag, perhaps as a part of the run command.

---

anecdotally, i separately remember seeing @mxr 's dotfile, and his alias for git commit -m "$msg" was actually something like git commit -m "$msg" || git commit -m "$msg" for a similar reason- he basically just wanted to take all pre-commit autofixes as a part of his commit, but still fail the commit if pre-commit didn't pass beyond those autofixes.

---

@asottile i'd like to hear whether this is something you'd be open to having in your project. and if you're open to it, i volunteer @mxr to write the feature

[asottile]

pre-commit doesn't have enough information to satisfy this -- and commonly tools exit nonzero when making changes so even if it were possible to have the information the two states would be indistinguishable (a tool "successfully" making changes vs. a tool making some changes and erroring). my recommendation is to pre-commit run --all-files || pre-commit run --all-files and is typically what I do

[ryanrhee]

i understand that pre-commit doesn't have the necessary information to satisfy this in one run, but what if a flag on the run command executed pre-commit once, and then if the first execution exits non-zero, executed it a second time, and returned the exit code of said second execution?

[asottile]

I think it's best to let the user perform that scripting if they need it, rather than need to maintain the complexity in the tooling

[asottile]

(and 2 might not be enough times -- it may need more times to "settle")

[ryanrhee]

Hm yeah good point on needing more than 2 invocations. Thanks for the quick responses!

[mxr]

Yeah it's a deliberate design decision that any hook changes require user confirmation, since hooks may not be trustworthy. There are closed issues about this already (I volunteer @ryanrhee to go find them)

This is my alias if you decide to trust your hooks 🤷