It’s free cache space 😏

This is a really cool post, thanks! I should make a page with links to weird things people do with DNS.

Yoink! New project logo haha ;P

Great question! I considered that, it’s what lead me to the idea to use DNS in the first place. The problem I had with that is that the ultimate URL path might change, not just the hostname. What happens if a repo has to move from github.com/org/repo to mycoolforge.net/repo?

But there’s also another reason that I realized as I was working out the details of git-remote-helpers: What happens if your remote needs to change protocols? With doink you can swap from http(s) to ftp with an ip address instead of a hostname, or perhaps even some (future) git-over-whatever-p2p-network.

So yeah if you’re swapping from a github-style forge to another github-style forge and you don’t need the flexibility, you definitely could just CNAME it! And that would probably be more robust, but it would also give you less future flexibility :P

It is now lol

I’m bad at naming things, so it was originally GHA (for github archiver, changed to good helpful archiver because trademark), but I kept misspelling it as GAH so it was just easier to change the name.

But the reference is way better :P

Oh hi, I forgot to reply to this!

My reasoning was mostly “I read it somewhere when I started coding and then didn’t do much with threads” to be honest. Not great reasoning there. But modeling the interactions between a user, UI thread, and work thread made it a lot easier to organize my code and create a good separation of concerns; the UI thread handles interface updates and dispatching events, and the worker thread works. Honestly that code organization was the biggest advantage I got out of doing things this way, and I wish I’d emphasized that more in the blog post.