Yeah, it's cool, people are mostly looking for something like your usecase. I got suggested stow or stow-like tools a lot when exploring this. And when they understood what I wanted, they just suggested ansible... Which would work when starting from scratch, but wasn't right for me. I made copicat mostly because I am actually using it, and then decided to make it public because really I didn't find anything like it.
Say you want to store /etc/ufw/sysctl.conf which is owned by root:adm and has permission 644 in your repo, but also /etc/ntfy/server.yml which is owned by ntfy:ntfy with permissions 664. How do you keep track of this with gnu stow?
That is a good question. I have considered using gnu stow before building this. But there's a couple of problems with that.
Git doesn't follow symlinks, it stores them as links in the repo, so your only option is to keep the files in the repo, and symlink from the config file location to the repo. This is fine for user config files (like from your .config folder), but if you want to keep system config files (like those from /etc) then the git process needs to run as root to modify those files, because symlinked files share permissions and ownership. And even then, git will always create everything as root because it only tracks permission bits, not ownership, so you will need to constantly fix up ownership of your files.
With this tool instead you explicitly tell it the ownership and permission of files, and it takes care of that for you (it still needs root permissions of course).
at the 33rd round you do
That's like... It's purpose. Compilers always have a frontend and a backend. Even when the compiler is entirely made from scratch (like Java or go), it is split between front and backend, that's just how they are made.
So it makes sense to invest in just a few highly advanced backends (llvm, gcc, msvc) and then just build frontends for those. Most projects choose llvm because, unlike the others, it was purpose built to be a common ground, but it's not a rule. For example, there is an in-developement rust frontend for GCC.
Counterargument:

Admittedly this is a chat app, so there's little to do. But still, it could stretch out a little bit more, maybe open the conversation info panel on the right
Straightest Griffith interaction.
Also, fuck Griffith
AI upscaling, I think
I am a computer scientist after all
If I get back to 2005 I can easily get more than 10 millions by the time it's 2024 again. Plus all the other perks of restarting your life
Dude what are you talking about, it was still here less than 15 years ago. The Nintendo Wii literally had an ATI GPU
Yes, that was one of the tools I considered before making this. I do not remember the precise detail on why, but much like gnu stow is only good for versioning user dotfiles and not system config. Etckeeper is good for storing either your system config files or user's dotfiles, but not both at the same time. copicat doesn't care what you use it for because you explicitly tell it all the locations and permissions that you want.