How can I enable old pre-commit behavior in 2023.1 upgrade?

Hello

Thank you for your feedback! 
Would you mind elaborating a bit more on your workflow?
How it looked like before and now?
Do you have to make a lot more of additional commits and not amending old commits? 
A comparison of workflows would help us to find a way to improve this part of commit-checks 

The same.

I just noticed that IntelliJ IDEA no longer runs code checks before committing code, which means we could end up committing code with missed issues.

But it's really important to have this feature so we can catch any issues before they get committed. So I want the previous behavior or just stay at 2022.3.

Hi Ruslan Kuleshov, thanks for replying.

Prior to the 2023.1 update, the commit process included pre-commit checks that would run when committing changes through the commit section. These checks would alert me if any problems were found. If any issues were detected, the commit would not proceed unless I chose to override the warning by selecting the 'commit anyway' option.

In the event that problems were detected, I would modify the files to address the issues and initiate another commit. The pre-commit checks would run again, and if all issues were resolved, the commit would go through. If any issues persisted, the checks would alert me once again, preventing the commit from proceeding until the issues were fixed.

Now, event if there are problems, the files are being committed and after that there's a notification detailing the errors.

This process was crucial in ensuring that my committed files were error-free and avoiding the need for redundant 'fix' commits. It allowed me to catch and address any issues before they were committed to the repository, ultimately improving the stability and quality of my codebase.

Same for me, I would like to see any warnings about my code before I commit the code, so that I can fix any issues and then actually do the commit, instead of having to do multiple commits and then squash them.

I also do not like the new behavior.

After a commit you might think, that everything is complete but it isn't because the checks are still running.
The analyzing may take a while, therefore you have to take this extra mental load to not to forget it.
Maybe you close IntelliJ and forget about it.
Or maybe you start to work on the next thing and then you are informed that your first commit was not ok.
Maybe you even commited this second change before the first one was analyzed.

Another thing: the checks of the sonar lint plugin run before the commit, but the other checks now run afterwards. This is an inconsistent behavior.

I wonder what is the advantage of commiting the change if it is not complete yet?
Of course you can use ammend commit or interactive rebasing to change the commits afterwards but I still see no advantage.

I don't like this behavior change at all.
I think there should at least be an option to choose if the checks run as pre-commit or after-commit.

Same for me. It's a shame to see warnings AFTER you commited them. 

anonymous
There is an existing request to perform the commit checks/analysis before actually committing the change: https://youtrack.jetbrains.com/issue/IDEA-316398

Please provide your feedback there on how this change affected your workflow exactly and why you find post-commit checks inconvenient. It will be taken into account with all other users' feedbacks and considered when implementing the change to resolve this usability problem.
You can also vote for the mentioned issue and follow it for progress updates.

Workaround 

https://youtrack.jetbrains.com/issue/IDEA-311316/Allow-turning-off-background-precommit-check#focus=Comments-27-7826680.0-0