5 ms·

What features do you think Gitlab lacks compared to GitHub? I haven't used the CI/CD features of either, but PR/MR features seem comparable. Is it the advanced

by nwah1 6y ago

What features do you think Gitlab lacks compared to GitHub? I haven't used the CI/CD features of either, but PR/MR features seem comparable. Is it the advanced workflow stuff and CI/CD integration where GitHub is better? Bots? I think git in general should copy the approach of Fossil and include issue management and wikis along with the repo, to keep things consistent and avoid vendor lock-in. But I would be a lot more worried about being locked-in to GitHub than Gitlab.

rock_hard 6y ago
Gitlab is worse on almost every angle compared to Github It simply lacks the attention to detail...you can tell that Github walks the extra mile to get the UX right. We used Gitlab for a year and then migrated to Github...it’s a joy!
- frenchyatwork 6y ago
  Having used both a fair bit, I don't know what you're talking about. If anything my experience has been the opposite. Gitlab had the second mover advantage on a few things, while Github's interface has some weird oddities that seem to stem from the fact that that's how they've always been.
- cortesoft 6y ago
  Interesting... we used GHE for 7 years and have now switched to gitlab. Gitlab CI, container repos, and Kubernetes integration has been amazing.
boogies 6y ago
> I think git in general should copy the approach of Fossil and include issue management and wikis along with the repo, to keep things consistent and avoid vendor lock-in. It does include git send-mail, and I think Sourcehut’s use of that for issues is nice (and they quote customer claims that “SourceHut mailing lists are the best thing since the invention of reviewing patches.”).
darkcha0s 6y ago
Let's not kid ourselves here, it's because GH is owned by MS.
- bawolff 6y ago
  Its not. This isn't 2000s /. M$ is teh evil!!!11. Its because GH is not available as self-hosted open source. Doesn't matter who owns it. Github was discussed and rejected by wikimedia back in 2012 as well, which was before MS bought them
brennen 6y ago
> I think git in general should copy the approach of Fossil and include issue management and wikis along with the repo, to keep things consistent and avoid vendor lock-in. A few paragraphs I recently wrote elsewhere: The entire state of code forges as a general thing in 2020 is all the evidence you could possibly want that version control systems (Git, I'm talking about Git) are themselves massively deficient in design. I rant about this all the time, but there is an entire class of argument about how & whether to use GitHub / GitLab / Gitea / Phabricator / Gerrit / sourcehut / mailing lists / whatever that would mostly vanish if the underlying data model in the de facto standard was rich enough to support the actual work of software development. Because it's not, we find ourselves in a situation where no widely used DVCS is actually distributed in practice, and the tooling around version control is subject to platform monopolization by untrustworthy actors and competitive moats. Code review should itself be distributed/federated, but few of the people involved have incentives to make that happen. It's possible something like https://github.com/forgefed/forgefed https://github.com/forgefed/forgefed will eventually get traction, and Git has been dominant for long enough that I wonder all the time when we might see a viable successor that learns from its fundamental mistake. In the meantime we're forced to choose from a frankly pretty terrible lot of options in the broad structural sense. (For clarity, I'm a WMF employee and am involved in the decision to migrate to GitLab.)
- judge2020 6y ago
  To me, it sounds like the issue is that you need a central source of truth that everyone can pull from for their purposes, and distributing the code review part doesn't sound like it'll add much. In the current climate, most anyone requesting code review is probably trying to merge into the main central source of truth anyways, so what actual benefit does it bring to either the maintainers or the contributors?
  - brennen 6y ago
    Version control for a genuinely long-lived project is a problem that often outlasts: - Dominant version control and code review system(s) / paradigms. - The current configuration of institutional owners. - Users' trust in an owner / sponsor / maintainer. (Forks happen for reasons.) - The involvement of developers who remember why and how decisions were made. - The trustworthiness of the entities that control services, applications, and network real estate used for development. Some central source of truth is usually necessary, but maintainers and contributors don't benefit when that source of truth is subject to vendor lock-in or can otherwise only migrate at great cost. For all the collaborative benefit that GitHub has undeniably wrought, platform monopolies are eventually a failure mode for end users, at least as for-profit enterprises. With the exception of the dominant silo vendors, nobody in the ecosystem really benefits from being forced to choose a silo that will be hard (and lossy) to escape later. The silos are engineered to limit mobility and channel interoperability to their own ends, for business reasons that run directly contrary to the interests of their users. If the protocol at hand were actually up to the task, we'd spend less effort and anxiety on the problems of all the non-protocol platform tooling that's been built up around it.

by nwah1 6y ago

rock_hard 6y ago

Gitlab is worse on almost every angle compared to Github It simply lacks the attention to detail...you can tell that Github walks the extra mile to get the UX right. We used Gitlab for a year and then migrated to Github...it’s a joy!

frenchyatwork 6y ago
Having used both a fair bit, I don't know what you're talking about. If anything my experience has been the opposite. Gitlab had the second mover advantage on a few things, while Github's interface has some weird oddities that seem to stem from the fact that that's how they've always been.
cortesoft 6y ago
Interesting... we used GHE for 7 years and have now switched to gitlab. Gitlab CI, container repos, and Kubernetes integration has been amazing.

boogies 6y ago

> I think git in general should copy the approach of Fossil and include issue management and wikis along with the repo, to keep things consistent and avoid vendor lock-in. It does include git send-mail, and I think Sourcehut’s use of that for issues is nice (and they quote customer claims that “SourceHut mailing lists are the best thing since the invention of reviewing patches.”).

darkcha0s 6y ago

Let's not kid ourselves here, it's because GH is owned by MS.

bawolff 6y ago
Its not. This isn't 2000s /. M$ is teh evil!!!11. Its because GH is not available as self-hosted open source. Doesn't matter who owns it. Github was discussed and rejected by wikimedia back in 2012 as well, which was before MS bought them

brennen 6y ago

> I think git in general should copy the approach of Fossil and include issue management and wikis along with the repo, to keep things consistent and avoid vendor lock-in. A few paragraphs I recently wrote elsewhere: The entire state of code forges as a general thing in 2020 is all the evidence you could possibly want that version control systems (Git, I'm talking about Git) are themselves massively deficient in design. I rant about this all the time, but there is an entire class of argument about how & whether to use GitHub / GitLab / Gitea / Phabricator / Gerrit / sourcehut / mailing lists / whatever that would mostly vanish if the underlying data model in the de facto standard was rich enough to support the actual work of software development. Because it's not, we find ourselves in a situation where no widely used DVCS is actually distributed in practice, and the tooling around version control is subject to platform monopolization by untrustworthy actors and competitive moats. Code review should itself be distributed/federated, but few of the people involved have incentives to make that happen. It's possible something like https://github.com/forgefed/forgefed https://github.com/forgefed/forgefed will eventually get traction, and Git has been dominant for long enough that I wonder all the time when we might see a viable successor that learns from its fundamental mistake. In the meantime we're forced to choose from a frankly pretty terrible lot of options in the broad structural sense. (For clarity, I'm a WMF employee and am involved in the decision to migrate to GitLab.)

judge2020 6y ago
To me, it sounds like the issue is that you need a central source of truth that everyone can pull from for their purposes, and distributing the code review part doesn't sound like it'll add much. In the current climate, most anyone requesting code review is probably trying to merge into the main central source of truth anyways, so what actual benefit does it bring to either the maintainers or the contributors?
- brennen 6y ago
  Version control for a genuinely long-lived project is a problem that often outlasts: - Dominant version control and code review system(s) / paradigms. - The current configuration of institutional owners. - Users' trust in an owner / sponsor / maintainer. (Forks happen for reasons.) - The involvement of developers who remember why and how decisions were made. - The trustworthiness of the entities that control services, applications, and network real estate used for development. Some central source of truth is usually necessary, but maintainers and contributors don't benefit when that source of truth is subject to vendor lock-in or can otherwise only migrate at great cost. For all the collaborative benefit that GitHub has undeniably wrought, platform monopolies are eventually a failure mode for end users, at least as for-profit enterprises. With the exception of the dominant silo vendors, nobody in the ecosystem really benefits from being forced to choose a silo that will be hard (and lossy) to escape later. The silos are engineered to limit mobility and channel interoperability to their own ends, for business reasons that run directly contrary to the interests of their users. If the protocol at hand were actually up to the task, we'd spend less effort and anxiety on the problems of all the non-protocol platform tooling that's been built up around it.