Hi, owner of GitGud.io here
>>Free - Yes, totally free for any user or group
>Such claims are invariably false. Or, stated most generously, heavily misleading, because of limitations.
Can you explain your issue with this? GitGud.io has been operating for over 8 years with only free accounts and without any paid setup. Historically we've been supported by user donations, but I now also pay out of pocket, a relatively trivial amount since my main job is being a DevOps engineer for a CDN & cloud company, for server resources and upgrades for GitGud.io and we have plans to launch SaaS products that will completely offset any GitGud.io costs.
>>Fast - One of the fastest git hosting services
>Holistically, I’d say this isn’t even possible if you’re using GitLab. Significant parts of GitLab are very slow. And as for GitGud.io at present, well, that repository’s URL is consistently taking about ten seconds to send the first byte of the response, and even HEAD / takes more than five seconds to issue a 302 redirect to /users/sign_in.
GitGud.io has historically been fast. Currently we just finished an upgrade of the main node last week from an 8-core Epyc to a 64-core Epyc, plus 2-3x more available memory and we have not had enough traffic to adjust this. This event helped us tune GitLab better to our new resources. And yes, as someone who has been working with GitLab for over 8 years, I know exactly how slow and bloated it is, but you must also understand that GitLab.com itself spent years being constantly down or hardly loading in comparison. Different scales of "users", but GitGud.io still has 41,000 users and close to 15,000 repositories. You'd be hard pressed to find many other GitLab instances publicly usable that big. We could utilize Gitea or something lighter, but GitLab offers a lot of features and Gitea didn't exist when we started.
>> Highly available - average uptime of 99.83% ¹
>Look, “highly available” is a vague term, but for this kind of service I’d expect it to mean three nines at the very least, probably four, and to mean an architecture and upgrade deployment mechanism significantly different from GitLab’s, where upgrades are disruptive.
>Also, their actual status page is currently saying 91.16% for the last 24 hours (2h7m of downtime), which is already more than two months’ downtime budget even at 99.83%.
Yes, cause currently we currently took the host node down 12 hours ago for a couple of hours in a planned hardware upgrade maintenance to install new 40g NICs, SSDs, etc. Overall the average is decent, and this line harkens back to the days when GitLab.com was down daily. We run on our own bare metal colo servers, not magically appearing cloud instances.
>> Reliable - We have never lost any data, unlike other services
>You also probably haven’t dealt with any of the scale-related issues that have caused data loss in said Other Services.
Their scale outs should have made it harder to lose data, not the other way around. We've also have ran a fairly large file/media sharing site in the form of Imgur with dozens of TBs of user uploaded media scaled across several servers, and we didn't lose data there. Fact is, we haven't lost any data and that's our track record so far over the past 8 years. I think that's worth of some note.
Either way, while the homepage claims are eyebrow raising for you, I don't see how this matters much for a service that is charging $0 for Git repo hosting. We make $0 for any user who decides to utilize us. If we wanted to charge for GitGud.io access and it's GitLab CI runner access, we could. There's nothing stopping us from doing that. But even if we disappeared tomorrow, the fact is that Git is naturally decentralized. The original creators and the clones exist somewhere.
We exist as an alternative to other services that suspend accounts on a whim and an easy solution for those that don't want to setup or pay for their own Git instance.