agateau

The code is the present truth, the commit messages can inform you about how it got turned into this truth. Interestingly, I recently wrote a short article about this: https://agateau.com/2026/on-commit-messages/

I wonder if the spare fiber connections could be use to mesh houses together, in a kind-of decentralized way?

I disagree with this: commit messages should explain the Why. For the What, I can read the diff. Sadly, many commit messages are about the What.

I guess it does not help that I dislike conventional commits :)

Would be curious to know if it works better than writing the Why as human-friendly paragraphs in the body of the commit message.

Most LLM articles depress me. At least this one made me smile, even if it's more about turning a dog into a random generator and generating games from random input.

Another one: depending on the language, 0 is either singular or plural. In French it's singular and it's always fun to see the denial in the eyes of my French colleagues when I tell them that 0 is plural in English.

> I have a very long regular expression (email validation of course) that doesn't fit on one line but no solutions I have found properly break the lines on page overflow.

Have you considered manually splitting the regular expression into multiple lines in the source document, using something like the `VERBOSE` mode from Python re module [1]?

[1]: https://docs.python.org/3/howto/regex.html#using-re-verbose

Looks handy!

I loved my HP 48G when I was in school (even if it was much slower than the Ti 81 it replaced when it came to graphing). I regret throwing it away because of the nostalgia, but I don't feel a need for using it these days.

As such I am genuinely curious about what rewards you get from using an engineering calculator in your work. That's an honest question: I would really like to have an excuse to get my hands on a 48G again!

Sounds like an character from the Asterix comic book :)

Shameless plug: I wrote a tiny script to install Firefox from their tar.gz, without requiring root access: https://github.com/agateau/tmfi.

I would find it easier to read with more sensible, non-abreviated variable names.

A little known fact about executables on Windows is that while it's not possible to remove a running executable, it's possible to rename it.

I use this in Clyde [1]: on Windows, when clyde needs to upgrade itself (which means uninstalling vN and installing vN+1) it renames itself from `clyde.exe` to `_clyde.exe`. I leave the old `_clyde.exe` around, but a nicer implementation could remove on the next start.

[1]: https://github.com/agateau/clyde

They should draw the complete d-pad and highlight the button to press instead.

I'd rather not. Never rode one, but I heard bullets are really impractical vehicles. My bike seems much more comfortable.

I used to take the subway in Paris. Now I ride a bike, carefully. I don't ignore traffic lights. And even riding this way I am always surprised that I'm faster than the subway. No connections, no wait, arriving directly at the exact destination helps.

Not to mention no need to stand in an overcrowded metal box.

I'd prefer a bullet, if it's traveling at 20km/h.

I use ripgrep everywhere, not only in my own repositories, so the first approach won't work for me. The second one, on the other hand, sounds like a really good idea, going to look into it, thanks.

And of course, thanks for this wonderful tool!

I love that ripgrep honors .gitignore, but the fact that it skips hidden files is annoying because of questionable decisions from tool makers who insist their configuration files should be hidden files. It is especially infuriating when working with GitHub and GitLab configuration directories. On the other hand I never want ripgrep to enter the .git directory.

I recently came up with this alias to make ripgrep do what I want: do not skip hidden files, except for the .git directory:

alias rg="rg --hidden --glob '!.git/'"

(Note: if you try entering this alias interactively, you may have to escape the '!'...)

I don't understand why people dislike GNU Info doc. I often do not think about checking them, because `man` is so ingrained in my brain, but when I do I often find them quite good. For example the info page for tar is much more complete than its man page.

This is the kind of tools I dislike. It does generate a "nice looking changelog", but the result is not as useful as a separately written changelog, because the content is not curated, so the signal-noise ratio can be quite high.