Oh, never heard of amnezia. Never needed actually. But it looks like a good improvement on Wireguard. I will need a separate setup to test it out and currently I’m away from home with no clue when I will return. If I happen to find anything, I will definitely ping you.
In the HN page you linked many people mentioned v2ray. Have you tried that? How good is it?
Have you considered having Headscale on a cheap VPS? We are actually doing that and it is pretty capable. IIRC, you can configure not to use the tailscale servers at all, and use your own public VPS for coordination. Bonus point, tailscale hired the Headscale developer and maintainer, and they are allowed to work on Headscale while on their payroll. The team looks very much into FOSS.
So this bit confuses me. The article says in the intent and scope section that the entire process of bug fixing, in the included example, is literal bug fixing, clean up toggle, correct lints, correct duplication. That point to linting issues.
The earlier section says that a commit should be ‘buildable’ and ‘testable’. So if there are linting issues, the commit won’t satisfy this criteria right?
What am I missing here?
Tried neovim a couple of times. Stopped after 10 or 15 mins. Anyone has useful tips to get used to vim/neovim?
Aah. I assumed linting was part of the build also. My bad. I did understand the idea you were mentioning. Just that assumptions kind of threw me off.
I wanted to ask something related to that. As you mentioned, git takes a snapshot of the repo on every commit. So splitting up the bug fix and other activities means you have 3 or 4 commits instead of one. Let us say we are dealing with a very large repo. This does not look ideal in that context right? So do you think the way you proposed is only suitable for smaller repos?