alt Hacker NewsMaybe I'm too old school, but both GitHub and Codeberg for me are asyncronous "I want to send/share the code somehow", not "my active workspace I require to do work". But reading
> the worst thing ever for me as a developer is having the urge to code and not being able to access my remote.
Makes it seem like GitHub/Codeberg has to be online for you to be able to code, is that really the case? If so, how does that happen, you only edit code directly in the GitHub web UI or how does one end up in that situation?
Replies
For some projects, the issue tracker is a pretty integral part of the documentation. Sure, you can host your own issue tracker somewhere, but that's still shifting a center point somewhere, in a theoretically decentralized system. I've frequently wished the issue tracker was part of the repository. Also -- love them or hate them -- LLMs would probably love that too.
My main exposure to Codeberg is Zig and it has an issue tracker there and I pull in changes from it.
For how infrequent I interface with Codeberg I have to say that my experience has been pretty terrible when it comes to availability.
So I guess the answer is: the availability is bad enough that even infrequent interactions with it are a problem.
> Makes it seem like GitHub/Codeberg has to be online for you to be able to code, is that really the case?
I can understand that work with other active contributors, but I agree with you that it is a daft state of affairs for a solo or mostly-solo project.
Though if you have your repo online even away from the big places, it will get hit by the scrapers and you will end up with admin to do because of that, even if it doesn't block your normal workflow because your main remote is not public.
You’re right this is the proper way to use git. And I encourage developers to use their own cloud storage (or remote volume) for their primary remote.
Even with the best habits, there will be the few times a month where you forgot to push everything up and you’re blocked from work.
Codeberg needs to meet the highest ability levels for it to be viable.
I was shaking my head in disbelief when reading that part too. I mean, git's whole raison d'etre, back when it was introduced, was that you do not need online access to the repo server most of the time.
For me it's a soft block rather than a hard block. I use multiple computers so when I switch to the other one I usually do a git pull, and after every commit I do a push. If that gets interrupted, then I have resort to things like rsyncing over from the other system, but more than once I've lost work that way. I'm strongly considering just standing up a VM and using "just git" and foregoing any UI, but I make use of other features like CI/CD and Releases for distribution, so the VM strategy is still just a bandaid. When the remote is unavailable, it can be very disruptive.