strboul blog

Best git habits worth doing

2025-08-24T00:00:00+02:00

Use a client
Make atomic commits
Sign your commits
Set up commit hooks
Use force-with-lease instead of force

Over the years, I've tried many workflows, shortcuts, and team conventions while working with git. No two teams worked the same way, but I found a handful of habits that consistently made my life easier. In this post, I'll share the habits and tools that are worth doing. These aren't strict rules or universal standards, just practical lessons learned from real-world projects.

Use a client

git was designed to work as a backend system. UX is not git's forte. Using a client makes your work easier and more visual.

My favorite client is lazygit. It allows me to perform many git operations through a simple interface and it runs on the terminal so that's very universal.

Make atomic commits

Atomic commits mean that each commit should represent one logical change. Avoid making a change in one commit and then overwriting that change in another commit on the same branch. This approach makes several things easier:

Code reviews become simpler
Debugging with git bisect works better
Reverting changes is straightforward

It's up to you if you amend commits manually and rebase or use fixup commits. Fixup commits are better choice before finishing the process, because it lets you see what you overwrite and easily revert changes if needed.

git commit --fixup <commit-sha-you-want-to-fixup>

You can also use a tool like git-absorb creating atomic commits automatically.

Also, if you use lazygit client, you can easily amend commits or create fixups through the interface.

Sign your commits

Signing commits is important for public repositories. git identities are not protected by security measures. Anyone can pretend to be someone else by using their name and email.

You can sign commits in two ways: GPG and SSH.

GPG was the first way to sign commits. However, I no longer recommend it because managing GPG is a complex process. Of course, it's still a valid choice.

SSH signature verification is available since the version 2.34. This works well if you already use SSH to connect to git repositories.

Add your SSH private key to the local repository:

git config --local user.signingkey <path-to-private-key>

Add your public key to the allowed signers file:

echo "$(git config --get user.email) namespaces=\"git\" $(cat ~/.ssh/<git-ssh-key>.pub)" >> ~/.config/git/allowed_signers
git config gpg.ssh.allowedSignersFile "~/.config/git/allowed_signers"

View signature status for commits:

git log --show-signature

Turn off signing for a specific repository if needed:

git config --local commit.gpgsign false

Set up commit hooks

pre-commit is the most popular tool for managing commit hooks. You can also create custom hooks by placing them in the .git/hooks folder.

My only advice here is that when setting up hooks, focus on getting the best value for your time. You do not need to automate everything to the full.

Use force-with-lease instead of force

When you need to rewrite shared history, use --force-with-lease instead of --force. This option prevents you from overwriting other people's commits that you have not seen yet.

Spaces of learning

2025-06-01T00:00:00+02:00

I still remember exactly where I was when I learned certain topics. When I first studied BFS and DFS, it was King's Day in the Netherlands and I had gone to the university library. The library was closed, so I had to roam on the streets and took breaks to read.

Another time, when I was learning about heaps, I was on a train, sunlight shining in through the window. Those little details stuck with me, and now I can't separate the concepts from the moments in which I learned them.

I've also noticed how much mood matters. When you're trying to learn something, it helps to be calm and not agitated, and to create an environment where distractions are blocked out.

Actually, blocking distractions is a whole topic of its own. That's for another time.

Direnv supports .env files

2025-02-08T00:00:00+01:00

direnv is a fantastic tool that automatically loads environment variables when you switch directories.

By default, direnv works with .envrc files, but it can also load .env files automatically. This feature isn’t prominently documented, but thanks to this GitHub comment, there's a simple way to do it.

Add the following line to your .envrc file:

dotenv_if_exists .env

Then, allow direnv to apply the changes:

direnv allow

Now, whenever you enter the directory, direnv will automatically load the .env.

Multithreading in Python

2024-03-12T00:00:00+01:00

Python threads are useful for isolating programs and performing background tasks.

import threading
import subprocess
import time

def calculate_sum(sleep, which_thread):
    time.sleep(sleep)
    result = 2 + 2
    print(f"{which_thread}: 2 + 2 = {result}")

def sleep(time, which_thread):
    process = subprocess.Popen(
        ["sleep", str(time)], stdout=subprocess.PIPE, stderr=subprocess.PIPE
    )
    exit_code = process.wait()
    status = "finished" if exit_code == 0 else "failed"
    print(f"{which_thread}: sleep '{time}' {status}. exit code: {exit_code}")

if __name__ == "__main__":
    threads = [
        threading.Thread(target=calculate_sum, args=(0, "Thread 1",)),
        threading.Thread(target=calculate_sum, args=(1, "Thread 2",)),
        threading.Thread(target=sleep, args=(5, "Thread 3",)),
        threading.Thread(target=sleep, args=("fail", "Thread 4",)),
    ]
    # Start threads
    for thread in threads:
        thread.start()
    # Wait for both threads to finish
    for thread in threads:
        thread.join()
    # The program will continue once both threads have finished
    print("Program completed.")

# Thread 1: 2 + 2 = 4
# Thread 4: sleep 'fail' failed. exit code: 1
# Thread 2: 2 + 2 = 4
# Thread 3: sleep '5' finished. exit code: 0
# Program completed.

Yet, threading in Python doesn't always inherently enhance performance. CPU-intensive executions may not fully exploit threading due to the GIL constraint but I/O-bound operations can still get some degree of benefit. There's some work on CPython that GIL may be removed in the future versions of Python (currently 3.12+ is the latest one).

How to stop auditd service

2023-05-07T00:00:00+02:00

You may sometimes want to stop the auditd service (hopefully temporarily!). Here the solution to overcome that error message that stops you in your tracks.

You command to stop the service and you get this weird error message:

sudo systemctl stop auditd.service
# Failed to stop auditd.service: Operation refused, unit auditd.service may be
# requested by dependency only (it is configured to refuse manual start/stop).
# See system logs and 'systemctl status auditd.service' for details.

Edit the auditd service configuration (Pick your favorite EDITOR):

sudo EDITOR=vim systemctl edit auditd.service

Then add the following lines at the top of the file, between the override remarks. That's how systemd service files are edited.

### Editing /etc/systemd/system/auditd.service.d/override.conf
### Anything between here and the comment below will become the contents of the drop-in file

[Unit]
RefuseManualStop=no

# ...

### Edits below this comment will be discarded
# ...

Reload the daemon and then you are able to start/stop the service as you want.

sudo systemctl daemon-reload
sudo systemctl stop auditd

Then there's no more frustrating error messages preventing you from stopping auditd (or any kind of systemd service).