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.

I agree, I used to have a NEWS file in my projects (later a NEWS.md), but as others commented, the signification of the term "changelog" has changed. Sites like https://keepachangelog.com/ really refers to release notes or news.

(Author here) Yes, "release notes" is probably the appropriate term. The issue remains however: many projects generate their release notes from their git commit messages.

Regarding the conflicts issue, this is where tools like Changie can help: instead of modifying one single file, every merge adds its own separated entry. They are then assembled together at release time with `changie batch $VERSION` to produce a single file for $VERSION, then merged into the global changelog/release notes file with `changie merge`.

I very much agree with this. Sometimes it's good to stop and think about what is lost when automating a task instead of doing it manually.

Shameless plug: I have been working on Pixel Wheels, a top-down, arcade racing game: https://agateau.itch.io/pixelwheels.

Nice! reminds me of copydeps (https://github.com/Genymobile/copydeps)

git gui, which comes with git, is quite efficient to do partial commits. I wrote an article about this a few years ago: https://agateau.com/2016/an-intro-to-git-gui/

CC-BY-SA is only for assets: code is GPL3 and Apache 2, see https://github.com/agateau/pixelwheels/#license

(author here)

I thought I would answer to some of the comments here.

> It's their place, their rules

Definitely true. And I am not going to try to go against those rules. But I believe I am allowed to voice my opinion about them.

> Use in-app purchases instead

This is definitely a valid option, but that requires diving into Google Pay, which from what I understand is not the easiest API to work with. It also means I have to maintain additional code for Google Play. More not-so-fun work to do for a side project.

> Make it a paid game

Another valid option, but given how everybody is used to free games on Android, I doubt it would get much success. It also does not help that Google Play disallows switching a published app from free to paid and vice-versa: it's a one-way decision.

I might end up going that way though, because it has the advantage of not having to write store-specific code. Pixel Wheels is not Android only: it also works on Linux, Windows and macOS, so not having to deal with store-specific requirements gives me more time to work on the game itself. The game would still be available for free on F-Droid and for pay-what-you-want on itch.io.

I also happen to run other open-source projects, and my goal with donations is to get people to support this open-source work, not just my work on this particular project. I don't expect to ever live from this: in my wildest dreams donations would let me spend a work-day per week or every two weeks to work on open-source projects.