potiuk commented on PR #29226:
URL: https://github.com/apache/airflow/pull/29226#issuecomment-1409988283

   > OK, so I should actually run `breeze static-checks --all-files 
--show-diff-on-failure --color always`, maybe we should update the static check 
section in breeze guide to reflect this: 
https://github.com/apache/airflow/blob/main/BREEZE.rst#running-static-checks
   
   This chapter explain examples of different ways you can run the checks - 
including  --all-files or --last-commit or just a single pre-commit id. And 
even links to the "pre-commit.com" for even more options (you can add 
--ref-from, --ref-to for example). The `--last-commit` is just a shorthand for 
`--ref-from HEAD^ --ref-to HEAD` in fact.
   
   It's up to you what you run and you need to consciously choose it.  The 
`--last-commit` only runs it on last commit - if you have multiple of those 
(because you add fixups) - it will only run the checks relevant to the last 
commit (i.e. last fixup). If you squash your all fixup (which I heartily 
recommend) then it will work as expected and run all the relevant changes. This 
is WAY  faster than running `--all-files` (which ~10 minutes on my 16-processor 
machine). Asking all users to run `--all-files` and loose 10 minutes every time 
is a bad idea. 
   
   Also if you follow the instructions and use `pre-commit install` - you do 
not have to run static checks at all usually. They will be run for you 
automatically when you run commit - only for the commit being committed right 
now. And if you rebase and amend your local commit, this means tha tin vast 
majority of cases it will take merely seconds or even less than that to run 
them.
   
   CI runs `--all-files` just to be sure that there are no unexpected 
side-effects. And when you se the output you are free for example to only run 
locally specific pre-commits that failed to save time with `--type` (the ID of 
the pre-commits is auto-completeable and when pre-commit fails in CI it prints 
the ID of it). 
   
   So eventually - it's you who are empowered here and decide what's best 
command to use. That's why we explain you the options that you need to 
understand consequences of and you should choose what you think is best in the 
situation.
   
   But if you have idea how to describe it better -  without impacting the 
freedom of choice and educating users like you on what to do, PRs are most 
welcome. Maybe my answer will give you better understanding that you will be 
able to explain better for users like you?
   
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to