Git: How to undo commits
To errr is human, to undo computer can help.
To errr is human, to undo computer can help.
You started a new branch, worked hard on initial commits, and you’re ready to send it for review. You try to push and:
Git hosts offer a “squash merge” option that merges a reviewed branch by combining all its commits into one. This leads to a linear Git history on your main branch, which is easier to understand and refer back to code reviews.
The Git community is gradually moving the default branch name from “master” to “main”, because the term “master” is hurtful to some people as it refers to slavery.
By default, if you mistype a Git command, it will list similar commands that you might have meant:
I just released version 1.11.0 of django-upgrade, a tool for automatically upgrading your Django project code. This release contains a lot of new features and fixes, thanks to new contributors including those at the Djangocon Europe sprints. Let’s look at the top changes.
Sometimes code uses boolean checks on variables that can only be true. This is normally a sign of a mistake, either in the type hints or the implementation. Mypy has an optional check that can find such problematic boolean usage with its truthy-bool error code.
You can use git rev-parse to show the SHA of the current Git commit:
In a lecture titled Where Does Bad Code Come From?, Casey Muratori introduced the acronym WARMED for categorizing the costs of code:
The Django 4.1 release notes feature this short, innocent-looking note:
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.
The original type hint proposal, PEP 484, initially allowed implicit optional types in function signatures. That is, a parameter with a default value of None would have its type automatically interpreted as optional. For example, this signature:
As type hints have evolved, Python has added simpler, more succinct syntaxes. But you still need to know the older forms, since Mypy uses them when reporting types.
--update-refsWhen working on a feature, you might split it into several stacked branches, so you can merge each one separately. But updating such branches can be annoying since you have to manage them independently. Git 2.38 (2022-10-15) made this management easier with the new --update-refs option, which can rebase a stack of branches at once. Let’s look at a couple of examples.
Exhaustiveness checking is a very handy type checker feature. It ensures that all possible types of a variable are handled. If your code changes to add another possible type, you can guarantee that exhaustiveness-checked code paths handle the new case.
In data import processes it’s often useful to have a “dry run” mode, that runs through the process but doesn’t actually save the data. This can allow you to check for validity and gather statistics, such as how many records already exist in the database. In this post, we’ll look at how to implement a dry run mode in Django by using a database transaction and rolling it back.
Python has no syntax to add type hints to lambdas, but that doesn’t mean you can’t use them in type-checked code. In this post we’ll look at how Mypy can infer the types for lambdas, based on where they’re used.
You want to pass your data from your Django view to JavaScript, in your template. And, you want to do it securely, with no risk of accidentally allowing malicious code injection. Great, this is the post for you!
Hynek Schlawack recently described graduality as Python’s super power: the ability to prototype in the REPL, and gradually add linting, type checking, and other practices to refine your code into maintainable, production-ready software. You can also apply graduality within tools, activating checks one at a time and fixing the resulting errors as you go.
partial() with transaction.on_commit() to avoid late-binding bugsDjango’s transaction.on_commit() allows you to run a function after the current database transaction is committed. This is useful to ensure that actions with external services, like sending emails, don’t run until the relevant data is definitely saved.
Normally your Django project’s deploy process runs the migrate command, and that takes care of updating your database as necessary. Especially on smaller databases, Django’s migration system can “just do it” for you.
Python’s requests package is very popular. Even if you don’t use it directly, it’s highly likely one of your dependencies does.
Slow queries happen, and when they do, it can be tough to dissect why they’re slow. This difficulty is compounded by using Django’s ORM, since it generates the SQL for you, so you may have little idea of the actual queries “under the hood”.
Investigating flaky tests is a dull necessity of testing. At least it is (in the best case) infrequent. Here are some shell commands you can use to automate steps in your investigations. These will work on (at least) bash and zsh.
Your PostgreSQL server is seizing up, with some naughty queries consuming too many resources or blocking others. Don’t panic! You can stop those problem queries and stabilize your system.