6 ms·
Gitlab, GitHub and SourceHut are remotely comparable only if you care just about source code hosting. But Gitlab (and partially GitHub) is so much more - it gre
by The_Colonel 2y ago
Gitlab, GitHub and SourceHut are remotely comparable only if you care just about source code hosting. But Gitlab (and partially GitHub) is so much more - it grew to a beast trying to do everything for your project - project management, CI, analytics, communication... It's not for everyone, but for e.g. startups buying an all-in-one solution could be attractive to reduce the effort on getting all development tools set up and integrated.
- krasin 2y agoSourceHut has an issue tracker (incomplete, but very fast) and CI. The problem is that SourceHut is not becoming any better over time. With all my respect to Drew, his attention is spread too thin over many projects.
- rgreekguy 2y agoI remember reading SourceHut's creator, Drew, has some controversy around him...
- krasin 2y agoEveryone doing anything has some controversy around them. At some point, we should just stop paying attention to internet dramas and focus on what matters. Like, fast issue trackers or continuous build with a novel feature to ssh into the state, when the build failed (which SourceHut supports: https://man.sr.ht/builds.sr.ht/build-ssh.md https://man.sr.ht/builds.sr.ht/build-ssh.md)
- stavros 2y agoGitlab does too, IIRC.
- AceJohnny2 2y agoHe is opinionated. Scroll through his blog, and I'm sure you'll find something to disagree on: https://drewdevault.com/ https://drewdevault.com/
- packetlost 2y agoIt's fine to be opinionated, but he's also very abrasive and you don't have to go far to find people who have had a bad experience with him at some time or another. That being said, I haven't seen anything egregious for a couple of years, so maybe he's taken some of the honest feedback to heart.
- shihab 2y agoMay I ask what does “very fast” mean in the context of an issue tracker?
- krasin 2y agoIt means that it's not slow. Case in point: Jira.
- _nalply 2y agoIt means that user feels the user interface is quite responsive. It's not a very useful metric. A user having a flaky internet connection with high latency and low bandwidth and intermittent disconnections would complain that the platforms he uses are "slow". Or a service is just bogged down by too many users but would be quite responsive if not overloaded. EDIT: I was not writing about JIRA specifically. I agree that JIRA is ALWAYS slow. Ten years ago I had to wait five seconds after a button click. However I also had to handle a complain that something was slow just because that customer's internet was shit. EDIT 2: I remember ten years ago an especially perverse variation. A friend of mine was complaining about the bad quality of video even after having upgraded his internet connection. The problem was asymmetric bandwidth. His friend had bad upstream and my friend just saw jerky movements and ugly artifacts and it was unusable for communication in a Signed Language. I learnt that day: if something is slow, then it is not always easy to understand why. My friend was very disappointed in me.
- creshal 2y agoJira is slow all the time. Sourcehut might, potentially, in contrived circumstances be at risk of becoming slow, but it's so well optimized that it's an outside risk, rather than a guarantee. Surely you understand the difference between the two categories of software?
- xigoi 2y ago> A user having a flaky internet connection with high latency and low bandwidth and intermittent disconnections would complain that the platforms he uses are "slow". On the contrary, a bad internet connection makes it much easier to distinguish slow and fast platforms.
- a-french-anon 2y agoYep, as a paying customer, I'm still waiting for a way to reach each project page from any other page. Literally the easiest thing to make in the world, but still in limbos... As for Gitlab and Github, I left ridiculous Jabbascript abominations behind and never looked back; Github now overriding usual keys like PageUp/Down and Home/End SPA style and not being able to display most stuff without JS is the straw that broke the camel's back for me.
- packetlost 2y agoI'm not saying I don't agree, but I'm sure they would accept contributions implementing such a feature.
- Justsignedup 2y agoAfter using gitlab for a year I can boldly claim that it is inferior to github in every feature with subtle things being better in github which add up to a far better experience. Gitlab tries to do a lot and never did anything that well. It's just perpetually catching up to github.
- Gigachad 2y agoPre Microsoft I felt Gitlab was a lot better. It had a lot more features that actually worked. This was an era where Github didn't even have a built in CI solution. Last time I used it, which was a few years ago now, it felt like Github had caught up and a lot of the Gitlab features were flaky or didn't seem to serve any purpose other than checking a sales tick list. Stuff like integrations that don't seem to really serve any purpose other than to say they are integrated.
- chipdart 2y ago> Stuff like integrations that don't seem to really serve any purpose other than to say they are integrated. I don't think integrations are the example you think it is. The ones I tried work well and make it trivial to setup features that would otherwise feel like papercuts. I'm talking about things like being able to handle gitlab events without having to manage anything or provide your own event-handling infrastructure. If you have web hooks you need invoke or react to, as anyone who runs full CICD and cares about blocked pipelines does, with GitLab you don't need to worry about exposing custom endpoints and write controllers. For many, that is the difference between using notifications or not.
- NewJazz 2y agoYou can't pull a docker image from a private github container registry without a personal access token. Gitlab's group and project level deploy tokens are great.
- chipdart 2y ago> After using gitlab for a year I can boldly claim that it is inferior to github in every feature with subtle things being better in github which add up to a far better experience. I find this remark baffling by how much it contrasts with reality. Others in this thread already commented on GitHub using terms like "mediocre". I wouldn't go that far but I am indeed aware that GitLab feels it works and is expected to work reliably, specially CICD which, unlike GitHub, they succeeded in turning it into a solved problem. It's even more baffling reading bold claims like "Gitlab tries to do a lot and never did anything that well" when only a couple of years ago GitHub Actions were renowned for not even being prod-ready,whereas GitHub CICD just works and works well without requiring investing any thought into it at all.
- voidr 2y agoWhat is so difficult in setting up and integrating GitHub with Jira for example, last time I did it, it was a few clicks? GitHub also has mediocre issue management and a wiki and we have GitHub Actions as well. You still need to integrate your cloud service provider with GitLab, which is exactly the same hassle as integrating it with GitHub.
- brnt 2y agoGitea/Forgejo also has much of that these days.
- dogsledsleddog 2y agoFor Github there's a sort of moat that it needs to work across IDEs, orgs, random people, etc. For Gitlab any org using it can harmonize on an IDE and the IDE can slowly introduce all of the CICD/collab with much better code quality and user experience than Gitlab since they rushed to copy Github rather poorly.
- attendant3446 2y agoYes, the beast. It's a monstrous thing that does everything and nothing particularly well.