Hey, I made a thing! It’s called doink. Doink gives you dynamic git remotes by using DNS TXT records as pointers.
I wrote a bit about how it works and what it’s useful for.
Anyway, do you ever thing about how DNS is a basically a decentralized key-value database? I think about it a lot :)
clever approach. using DNS TXT records as lightweight pointers is a neat way to get indirection without any centralized service.
the DNS-as-key-value-store angle is underrated. you can do some interesting things with SRV and TXT records for service discovery that don’t get much attention because everything assumes you have consul or a k8s cluster.
does it handle TTL caching gracefully? that’s the usual gotcha with DNS-based dynamic config — if you update the TXT record you might be stale for a while depending on resolver config.
If you use ssh for the remote you can just add a line to ssh config mapping the remote to whatever. Of course you still have to change the config if things change, but you’re not relying on DNS. Used to be the way to handle multiple auths to github when dealing with client repos before they had better organization/enterprise & team support.
If you have control of the dns server, why do you need the bash script? Just create a CNAME record pointing to the current remote.
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
