(All tags.)
Git hooks are useful for enforcing standards in your repositories. But sometimes, they’re in the way and you gotta skip ’em (locally), such as when writing “WIP” commits, experiments, and even testing hooks. Here are a few techniques for skipping hooks.
The pre-commit framework lists hundreds of hook repositories on its hooks page. You can drop these into your configuration file and get a tool running in seconds. But there are many more tools out there that you might want to use, which you can run with custom configuration.
POSIX permissions include the execute permission, which allows the file to be executed as a program. The permission can be set for each of the three classes: user, group, and others. So, for example, you can have a file that is executable only by its owning user.
pre-commit uses Git’s hook system to run tools when you commit. Unfortunately, Git doesn’t run any hooks when making a commit during a rebase. This can lead to you rebasing a branch and not realizing some code needs fixing, at least not until your CI system runs pre-commit (say, with pre-commit.ci).
pre-commit’s main mode of operation is to run hooks against changed files when you commit. But you can also run hooks without committing, using pre-commit run.
PNG’s can be losslessly optimized to reduce their file size, by picking a better compression algorithm for the given image. The savings can be significant, like 50% (especially for macOS screenshots). This is an easy way to make web sites load faster.
Django deprecates a small list of features with every feature release, requiring us to update our projects, which can be monotonous. Today I’m announcing a new tool I’ve created, django-upgrade, that automates some of this drudgery for us all.
Black is the de facto standard code formatter for Python, and these days I use it on all my projects. blacken-docs is a tool that also allows you to apply Black to code samples in your docs. I recently rolled it out on my projects to great effect.
For all my linting needs these days I use the pre-commit framework. It has integrations with every tool I want to use, and uses Git’s hooks to prevent non-passing code from ever being committed.
When you run Django’s manage.py makemigrations, it will try to generate a name for the migration based upon its contents. For example, if you are adding a single field, it will call the migration 0002_mymodel_myfield.py. However when your migration contains more than one step, it instead uses a simple ‘auto’ name with the current date + time, e.g. 0002_auto_20200113_1837.py. You can provide the -n/--name argument to makemigrations, but developers often forget this.