2:20 the right way to pass arguments in shell is `"$@"`. `$*` will trigger all sorts of replacements including (but not limited to!) splitting argument on space. this can get you into lots of trouble depending on what is actually passed. (Without consulting git and shell docs, I'm afraid one can't really rule out even things like remote code execution -- imagine commit message was passed which contained `;` or `&` which starts new command...) ...and in case someone wonders, `"$*"` won't fix it, since it will weld all arguments into one. `$*` is almost never really useful. With the "magic at-sign" in `"$@"`, on the other hand, it will actually resolve to same number of arguments (zero to any number) as is passed, and the quoting will be interpreted as if you quoted every argument separately.
Pretty much every Python project of mine has pre-commit configured, with autoformatting, linting, and if possible type checking as pre-commit hooks. In most projects we also run poetry-check if we use poetry. It's just such a neat way to keep your code consistent and always neat.
I usually use them to apply linters! Black, ruff, and isort, specifically. Then i usually have a CI check that runs the same pre-commit hook to make sure PR's are linted. However, if someone is committing unlinted code, I've had a lot of trouble with people making relative branches from the unlinted branch and then failing CI because of the other branch.
I’m going to switch back to longer videos only from next week. I noticed that I’m not able to cover the topics as well as I want to in these shorter videos.
@@ArjanCodes You can always do short videos and elaborate in longer videos if the reception is good and people want to know more. I can imagine not all the topics are of equal interest to your audience. Nice vid thanks
I use them to enforce the contents of certain files. For example, we use an alternate repo store instead of pip, so I make sure that requirements.txt contains --extra-index-url at the top of the file plus some other stuff. And the usual checks: black, isort, flake8, plus things like pyupgrade to make sure we're using appropriately pythonic features It's super useful to maintain consistency across repos
I use it for linting with black. A collegue of mine uses git-hooks to strip notebooks before committing. I however like to keep the notebooks output, as I use them to document my exploration.
I have offloaded the linting to my CI/CD Pipeline, as I prefer being able to quickly commit before I leave. However, I do have a pre-commit hook that checks if I am not committing my ansible-vault unencrypted after changing the variables. Just a small safeguard to avoid silly mistakes.
I have a client that doesn't know how to use git. I am sometimes worried he doesn't update the scripts I send him. I used git pre-commit hook to save the hash of the previous commit to file and now it will be printed and logged every-time he runs the file so I will be sure he is up to date.
I use 2 so far. Commit msg hook to ensure the message starts with feat fix etc and has a character limit. Pre push hook to double check I'm not pushing up any debug code eg. Print / console.log statements.
Yup, using pre-commit and the pre-commit project and a large number of code formatters and linters to ensure code consistency and quality across teams. You shouldn't have one dev commit to a file and then another dev only resave the file in their editor and end up with changes (for example a dev always ensures that a file ends with a new line and doesn't allow for trailing whitespace can end up in this situation if the previous dev's editor allowed for such things). I also recommend adding cspell for checking functional correctness in languages like yaml where mis-spellings can be syntactically correct but not functionally correct (I've given talks on this in the past 😅)
I use pre commit hooks for black, isort, ruff, spellchecks, linting yaml files and and checking for secrets in my code. If you know any other important git hook please comment below
In a CI pipeline? Not so useful. Locally? Very. It's annoying to wait 5 minutes for a build, only to find out you forgot to fix a formatting error. Pre-commits are a time-saver here. But then I'd also recommend you use `pre-commit` (the application). Figuring out the yaml config will take a bit of time, but once you have it, you can extend it easy. `pre-commit install`, `pre-commit run -a`, `pre-commit uninstall` is basically what you need to know.
Just make your Python script executable and give it the correct name. No need for a shell "wrapper". Not sure if that works on Windows though, but you are using WSL right?
Arjan I am your long timed subscriber but could you please check your mic's input for that the s s s sound in your voice that is usually a lot irritating while watching quality content like your's.
It gives me an idea to make a pre-commit hook to just concatenate as a prefix to the commit message the ticket ID of the ticket I'm working on. Since the project I'm working for has a server side hook that rejects pushes of any commits that in their messages do not contain a ticket ID pattern, this is how we keep traceability between tickets/branches/commits/PR/etc. This is just to avoid having to write the ticket ID that I don't remember every time I make a commit.
I use pre-commit since 2 years for code quality There are some pre-commit extensions that execute flake, linters, etc ... We used it also for commit naming conventions
Used the hooks to check with a DB on the network if files should be set read-only, thus allowing emulation of the checkout behavior of a pre-git version system. This was needed since labview altered the file even if no source was changed (it stored the sources and bytecode and linkinfo in the same file. The last one changed at each run!)
💡 Get my FREE 7-step guide to help you consistently design great software: arjancodes.com/designguide.
2:20 the right way to pass arguments in shell is `"$@"`. `$*` will trigger all sorts of replacements including (but not limited to!) splitting argument on space. this can get you into lots of trouble depending on what is actually passed. (Without consulting git and shell docs, I'm afraid one can't really rule out even things like remote code execution -- imagine commit message was passed which contained `;` or `&` which starts new command...)
...and in case someone wonders, `"$*"` won't fix it, since it will weld all arguments into one. `$*` is almost never really useful.
With the "magic at-sign" in `"$@"`, on the other hand, it will actually resolve to same number of arguments (zero to any number) as is passed, and the quoting will be interpreted as if you quoted every argument separately.
Pretty much every Python project of mine has pre-commit configured, with autoformatting, linting, and if possible type checking as pre-commit hooks. In most projects we also run poetry-check if we use poetry. It's just such a neat way to keep your code consistent and always neat.
I usually use them to apply linters! Black, ruff, and isort, specifically. Then i usually have a CI check that runs the same pre-commit hook to make sure PR's are linted. However, if someone is committing unlinted code, I've had a lot of trouble with people making relative branches from the unlinted branch and then failing CI because of the other branch.
Why run black, ruff and isort when ruff is enough? Genuinely curious.
Do you have you Git hook code to show ?
These Tuesday tips are good. But it only touches the subject, but your deep dive videos actually helps to know concepts and underlying workings more.
I’m going to switch back to longer videos only from next week. I noticed that I’m not able to cover the topics as well as I want to in these shorter videos.
@@ArjanCodes good for us 🤣
@@ArjanCodes You can always do short videos and elaborate in longer videos if the reception is good and people want to know more. I can imagine not all the topics are of equal interest to your audience. Nice vid thanks
I use pre-commit hooks mostly to apply formatting (black, isort), and linting (flake8).
I use them to enforce the contents of certain files. For example, we use an alternate repo store instead of pip, so I make sure that requirements.txt contains --extra-index-url at the top of the file plus some other stuff. And the usual checks: black, isort, flake8, plus things like pyupgrade to make sure we're using appropriately pythonic features
It's super useful to maintain consistency across repos
I use it for linting with black. A collegue of mine uses git-hooks to strip notebooks before committing. I however like to keep the notebooks output, as I use them to document my exploration.
This is actually very useful to know, thanks!
Glad it was helpful!
I use it to run Black and iSort. I stick to formatting for git hooks.
I also had it. And then replaced both of them with ruff, as it's just much faster.
And Flake8. But then, I replaced all three with Ruff and I can't be more happy. It's blazing fast in my VSCode. No waiting at all.
I have offloaded the linting to my CI/CD Pipeline, as I prefer being able to quickly commit before I leave. However, I do have a pre-commit hook that checks if I am not committing my ansible-vault unencrypted after changing the variables. Just a small safeguard to avoid silly mistakes.
I'm confused when you did git commit it had the arguments '-m' and the message but the script said it had no arguments
I have a client that doesn't know how to use git. I am sometimes worried he doesn't update the scripts I send him. I used git pre-commit hook to save the hash of the previous commit to file and now it will be printed and logged every-time he runs the file so I will be sure he is up to date.
Same as everyone else it seems. I just use pre-commit to run black, mypy, flake8, pytest, etc.
I use 2 so far.
Commit msg hook to ensure the message starts with feat fix etc and has a character limit.
Pre push hook to double check I'm not pushing up any debug code eg. Print / console.log statements.
Yup, using pre-commit and the pre-commit project and a large number of code formatters and linters to ensure code consistency and quality across teams. You shouldn't have one dev commit to a file and then another dev only resave the file in their editor and end up with changes (for example a dev always ensures that a file ends with a new line and doesn't allow for trailing whitespace can end up in this situation if the previous dev's editor allowed for such things).
I also recommend adding cspell for checking functional correctness in languages like yaml where mis-spellings can be syntactically correct but not functionally correct (I've given talks on this in the past 😅)
Oh, also, add pre-commit as a check in your CI so that if someone hasn't installed pre-commit locally you find out before the changes get merged
Concise video, thanks!
Glad you enjoyed it!
Now show us how to save your pre-commit to a repo, and make use of the `pre-commit` application in a `.pre-commit-config.yaml`.
Please can you do a getting started with git in a similar format to your tutorials using poetry because those were brilliant!
Using pre-commit hooks for preventing secrets to be commited to the SCM
I use pre commit hooks for black, isort, ruff, spellchecks, linting yaml files and and checking for secrets in my code. If you know any other important git hook please comment below
What kind of scenario would be useful for these kind of hooks over a pipeline?
Tighter feedback loop. Do it in the dev machine instead of some remote machine where the env needs to be set up all over
In a CI pipeline? Not so useful. Locally? Very. It's annoying to wait 5 minutes for a build, only to find out you forgot to fix a formatting error. Pre-commits are a time-saver here.
But then I'd also recommend you use `pre-commit` (the application). Figuring out the yaml config will take a bit of time, but once you have it, you can extend it easy. `pre-commit install`, `pre-commit run -a`, `pre-commit uninstall` is basically what you need to know.
Just make your Python script executable and give it the correct name. No need for a shell "wrapper". Not sure if that works on Windows though, but you are using WSL right?
when committing - running linters, when pushing - run UTs and fail the push if the UTs fail
Arjan I am your long timed subscriber but could you please check your mic's input for that the s s s sound in your voice that is usually a lot irritating while watching quality content like your's.
It gives me an idea to make a pre-commit hook to just concatenate as a prefix to the commit message the ticket ID of the ticket I'm working on.
Since the project I'm working for has a server side hook that rejects pushes of any commits that in their messages do not contain a ticket ID pattern, this is how we keep traceability between tickets/branches/commits/PR/etc.
This is just to avoid having to write the ticket ID that I don't remember every time I make a commit.
We use this to integrate with jira so the code reviewer can approve or disapprove a commit for QA workflow
Am I first
I use pre-commit since 2 years for code quality
There are some pre-commit extensions that execute flake, linters, etc ...
We used it also for commit naming conventions
How can you check naming convention using precommit ?
@@nashiki4792 i mean commit message for exemple a commit message should be [IMP][1236] bla bla bla, then you can write a hook that will check this
Used the hooks to check with a DB on the network if files should be set read-only, thus allowing emulation of the checkout behavior of a pre-git version system. This was needed since labview altered the file even if no source was changed (it stored the sources and bytecode and linkinfo in the same file. The last one changed at each run!)
One of the use we do in our project is to use pre-commit to enable code formatting (black formatter)
One case of git hooks that I can think of is running some sort of pre-push integration testing.