Tools

Every few months I run git branch in a repository I work with every day and see a long list: fix-..., add-..., try-.... Most of these branches are pull requests that were merged weeks ago. Git doesn’t delete them by itself, so they just stay there. Until now, I cleaned them up with a one-liner like this: git branch --merged origin/main | grep -vE '^\*|^ *main$' | xargs git branch -d It works, but it’s easy to get wrong. If you forget the grep, main is in the list too. Every branch is compared with the one ref you typed. And there is no way to say “please keep this one”. ...

We push and pull container images every day. docker push shows a few progress bars, and the image is in the registry. docker pull brings it back. For most of us, it’s a black box, and it works fine until something goes wrong. Have you ever compared the IDs? podman build prints one ID. The registry knows the image by a different digest. And the push log shows two more digests, but the registry has no blobs with these names. Which one is “the image”? Or a push fails with DIGEST_INVALID or MANIFEST_INVALID, and it’s not clear what the registry didn’t like. ...

Every merge conflict ends the same way. You fix the files, and then you have to stage them. And this is exactly the moment when a small accident happens: most of us type git add -u or git add . out of habit. Both commands stage everything that is modified, not only the files you have just resolved. I’ve been bitten by this more than once. A set -x or a debug print in some unrelated file quietly goes into the merge commit together with the resolution. Nobody notices it, because nobody reads merge commits line by line. A few weeks later someone asks why the start script suddenly prints every command. ...