7 ms·

GitLab community advocate here! I wanted to let everyone know about a challenge we're holding right now. If you send us your review of GitLab vs GitHub (whether

GitLab community advocate here! I wanted to let everyone know about a challenge we're holding right now. If you send us your review of GitLab vs GitHub (whether positive/negative/neutral), we'll send you some swag. We know competition is good for end-users, so now it's our turn to evaluate what we're doing right and what we can improve upon. https://about.gitlab.com/blog/2020/04/14/github-free-for-teams/ https://about.gitlab.com/blog/2020/04/14/github-free-for-tea...

earthboundkid 6y ago
Competition is good for the end user, but ISTM that Microsoft bought the biggest player in the space so that they could drown the competition in the bathtub and monopolize the market. It's a smart play from Microsoft's point of view, but FTC should never have permitted the acquisition in the first place and should prosecute them for illegal dumping now.
- stevehawk 6y ago
  Github and Gitlab are not so important to any market as to warrant federal intervention. Both of them are easily replaced by anyone standing up their own git server. Not to mention the countless other code repository sites / software packages.
  - marceloabsousa 6y ago
    I disagree. Github and Gitlab are so much more than just code hosting platforms. Their ability to influence software development is increasing to the point that if both Github and Gitlab suddenly disappear the consequences would be quite dramatic.
  - johannes1234321 6y ago
    Moving of isn't easy - thanks to GitHub pages and markdown rendering your tool's homepage is the Git{Hub|Lab|...} page. That page is linked from "everywhere" else and indexed in search engines - all history aside from code is in there (discussions in bug issues and pull requests etc.) getting them out is possible, but all the linkage between commit messages and those might be problematic to migrate - contributors are often only known by their handle on that page, migrating of requires new setup of permissions and mapping of usernames to trust on a social level - there are tons of hooks configured for many projects - as GitHub Actions and GitLab CI gain more and more traction workflows depend on those "Just move the repo" is a fallancy which doesn't work. I have no doubts medium term about Microsoft steering GitHub, but I fear a single entity being so central in the opensoruce world (also consider npm acquisition etc.)
  - earthboundkid 6y ago
    Wow, a true HN “I could do that in a weekend”. Good point, all software is trivial and anyone could recreate a website with thousands of man hours behind them in a long weekend.
    - stevehawk 6y ago
      Are we suddenly pretending that Redmine and others don't exist for self hosting?
      - earthboundkid 6y ago
        Yes, there are lots of options in the space, but no one wants to use an option that is 75% as good as Github and still costs more. The only way to gain marketshare is to either get bundled into an enterprise contract (so it doesn't matter if you suck) or be better than Github and still underprice your product. Even Google gave up on their code hosting option because there's no way to get market share without setting money on fire. God bless Gitlab, but if Microsoft keeps supporting Github like this (and the FTC keeps taking long naps), they're going to run out money and die.
pattrn 6y ago
Don't really have the time to do a complete write-up, but for what it's worth I've completely moved my company from GitHub to GitLab within the past year. We found the group and project hierarchy to work very well for organizing our clients and their projects, and we've made extensive use of your CI/CD. The only real complaint I have is about the Auto DevOps feature you released. We're currently using this for a number of smaller projects, and we've found the documentation around customizing deployments severely lacking. We ended up just reading through the Auto DevOps repository since it was clearer and more complete than any online documentation, which eventually allowed us to work through all of the issues we were having. Other than that, it has been a wonderful experience. Thanks for a great product!
- emilycook 6y ago
  Thanks for the feedback! It's funny you mention the Auto DevOps documentation because we just had our new senior tech writer pick up an issue [1] to completely redo it, so hopefully it'll be more intuitive soon! [1] https://gitlab.com/gitlab-org/gitlab/-/issues/30933 https://gitlab.com/gitlab-org/gitlab/-/issues/30933
7777fps 6y ago
Looking through that comparison, I find it funny that "time tracking" is touted as a feature. My grand-boss might love the idea but the fact that GitHub is missing time tracking is a blessing as a developer. Making developers track their time is hostile. Development is not something you should clock in and out of. A time-box in JIRA or GitHub shouldn't replace management being aware of what their team(s) are working on and how their progress is. It too often turns into a stick to beat developers with. There are all kinds of better metrics by which to hold developers accountable. Tracking time just puts developers off from improving code or refactoring. If you write bad code it's not your time that suffers, it's the next developer who has to work on that section.
- emilycook 6y ago
  That's interesting feedback, I'll pass it along to the product team, although this is an angle they've probably thought about more than I have. The way we use it isn't really as an accountability metric, more of an estimate that can change dynamically when new problems arise so we can roughly plan out when a feature is going to be released. Granted we don't have a boss who would beat us over the head with that. Thank you for the feedback though I'll make sure to pass it along.
  - kirubakaran 6y ago
    > Granted we don't have a boss who would beat us over the head with that. For every boss that wouldn't, there are a hundred bosses that would, with very little understanding of what is even being measured. Sure, the "guns don't kill people, gun users kill people" argument applies, but maybe don't hand people free guns with their milk purchase?
    - emilycook 6y ago
      Oh no I agree, that was just a comment recognizing that my experience is different because I'm in a more ideal situation than other developers are surely dealing with. I still passed along the feedback to our product team!
- 6y ago
prosim 6y ago
The comparison states that "With GitLab, you get even more features than GitHub Team" and then lists code owners, multiple issue and PR assignees, or standard support. All these features are included in GitHub Team for $4 per month, so this whole section of the blog post is misleading. Also, you may want to point out that GitLab only offers annual billing, so the minimum charge on GitLab is $48. Some of my hobby projects only run a couple of months, so GitHub is the better choice.
- emilycook 6y ago
  Thanks for the feedback! I passed it on to our content team to see if they want to make adjustments to the blog post. I definitely don't want it to come across as misleading.
shred45 6y ago
Hey, also don't have a time for a full review, but had one comment. I've been a pretty passionate user of GitLab for 2+ years and really loved the industry-leading integrated CI/CD. I have found that page load times on both GitLab and GitHub, however, are pretty bad, with GitLab being the worst. Many administrative tasks, such as logging in -> finding repo -> checking a ci/cd test -> merging / releasing the branch, take 10+ page loads, and each one is quite slow. I ended up moving my personal projects to sourcehut simply because pages are more lightweight and server response times are faster. If GitLab could spend some time reducing the number of pages required for common tasks (not asking for a single-page-app!), and could reduce page load times as much as possible (I know this isn't trivial with Rails), I think that would greatly reduce the friction I feel when using the produce.
- emilycook 6y ago
  Thank you so much for the feedback! I'm asking around to see if there are any projects open to reduce the number of pages, but I do know for sure that reducing page load times is an issue we're working on. Here is our handbook page that outlines our current metrics and goals, our primary goal is to have a speed index of less than 2 seconds per each page on .com: https://about.gitlab.com/handbook/engineering/performance/ https://about.gitlab.com/handbook/engineering/performance/
  - ddevault 6y ago
    I know I'm biased here (full disclosure: sourcehut guy here), but I really hope you'll bring that goal even lower. I recently did a comparison between GitHub, GitLab, and SourceHut on the same "worst-case" page: https://git.sr.ht/~sircmpwn/linux/tree/master/arch/arm/boot/dts https://git.sr.ht/~sircmpwn/linux/tree/master/arch/arm/boot/... https://github.com/torvalds/linux/tree/master/arch/arm/boot/dts https://github.com/torvalds/linux/tree/master/arch/arm/boot/... https://gitlab.com/ddevault/linux/-/tree/master/arch/arm/boot/dts https://gitlab.com/ddevault/linux/-/tree/master/arch/arm/boo... cold cache warm cache git.sr.ht: 1.4s 72K 1.4s 48K github.com: 3.3s 635K 3.0s 317K* gitlab.com: 3.1s 1300K 1.6s 58K+ * Hides half of the files + Only the initial load, it loads a bunch of stuff with JS to keep populating the page afterwards, and has severe performance issues simply using the page (on Chromium, it was straight up unusable on qutebrowser) Even after the page loads, for me it's impossible to use. On a more forgiving "best-case" page, GitLab has poor performance: https://git.sr.ht/~sircmpwn/scdoc/tree/master/src https://git.sr.ht/~sircmpwn/scdoc/tree/master/src https://github.com/ddevault/scdoc/tree/master/src https://github.com/ddevault/scdoc/tree/master/src https://gitlab.com/ddevault/scdoc/-/tree/master/src https://gitlab.com/ddevault/scdoc/-/tree/master/src cold cache warm cache git.sr.ht: 296ms 28K 198ms 4K github.com: 572ms 360K 629ms 36K gitlab.com: 1310ms 1311K 1110ms 16K You should definitely make performance a core focus IMO.
phoe-krk 6y ago
Is it possible to submit replies via Fediverse or mail? Asking since I do not have a Twitter account and do not want to create one.
Normal_gaussian 6y ago
I don't have a blog to blog on yet, and you are likely looking for that to get some positive backlinks, but here are my two cents anyway. I use both for work - and gitlab by preference: * On the whole they are now close enough that I don't worry about the choice * Both are slow. Silly slow. A 2 second target for page loads is horrific. Jumping around a file structure and exploring blame is really really painful; but 90% of the time I'm on the pipelines page and its so so so slow. Its actually faster for me to have my pipelines webhook a private server for a faster dash. * GitLab is better for CI/CD. Easier, more sensible. I use it all the time; I set new clients up on it. * Gitlab is better for k8's - several clients use it and love it. * Search sucks on them both. They both give a paginated list when what I always want is a place in repo / filetype / etc. filter, post initial search (i.e, I'm looking for loadModule in webpack, I want to ignore tests (when I didn't know which was the test folder before searching), and jump between definition and usage, as well as find out if there is any documentation. Its not worth doing each individually. I want all at once) * API's are really slow. GitLab is probably worse here. My default webpage (localhost home page) is a dashboard of quick links and widgets. One of those widgets shows my failing pipelines. It takes 6 seconds on a good day. I bypassed it (as above) to let me be more responsive. I didn't have to bother bypassing it w/GitHub * On my NAS I maintain images of GitLab hosts and backups of all my repos. I have an image of the self-hosted gitlab we had at a previous (it closed) company. Being able to fall back to self-hosted is the oft-touted godsend, but being able to restart a retired self-hosted has literally made me and the others involved several thousand each (twice old clients have wanted a one off job. GitLab is the core of testing and deploying infrastructure).
- kennyGitLab 6y ago
  GitLab Product Leader here - > * Both are slow. Silly slow. A 2 second target for page loads is horrific. Jumping around a file structure and exploring blame is really really painful; but 90% of the time I'm on the pipelines page and its so so so slow. Its actually faster for me to have my pipelines webhook a private server for a faster dash. Agreed - and we're working on performance improvements for GitLab.com. Do you use GitLab.com or a self-managed instance? > * GitLab is better for CI/CD. Easier, more sensible. I use it all the time; I set new clients up on it. Thanks - I'll give the feedback to the teams to keep up the good work. We do focus on sensible defaults and easy setup. > * Gitlab is better for k8's - several clients use it and love it. Awesome to hear, I have some heritage with this part of the product so I'm glad you love it. > * Search sucks on them both. They both give a paginated list when what I always want is a place in repo / filetype / etc. filter, post initial search (i.e, I'm looking for loadModule in webpack, I want to ignore tests (when I didn't know which was the test folder before searching), and jump between definition and usage, as well as find out if there is any documentation. Its not worth doing each individually. I want all at once) We have a recent integration with SourceGraph, have you tried that out? https://docs.gitlab.com/ee/integration/sourcegraph.html https://docs.gitlab.com/ee/integration/sourcegraph.html > * API's are really slow. GitLab is probably worse here. My default webpage (localhost home page) is a dashboard of quick links and widgets. One of those widgets shows my failing pipelines. It takes 6 seconds on a good day. I bypassed it (as above) to let me be more responsive. I didn't have to bother bypassing it w/GitHub Uggh - I'm sorry. I don't quite understand your reference to a default webpage and widgets. Is it pulling from GitLab APIs to give you a dashboard of your development work? > * On my NAS I maintain images of GitLab hosts and backups of all my repos. I have an image of the self-hosted gitlab we had at a previous (it closed) company. Being able to fall back to self-hosted is the oft-touted godsend, but being able to restart a retired self-hosted has literally made me and the others involved several thousand each (twice old clients have wanted a one off job. GitLab is the core of testing and deploying infrastructure). I didn't follow this one explicitly either. I'm glad you've got backups, are you suggesting GitLab needs some improved restore capabilities from backups?
soulnothing 6y ago
I've wanted to do a deep dive into Github vs Gitlab for projects. But I'm a bit hesitant to have that on my blog. Unfortunately most places I've been pushing for anything other than Github is not well received. That being said I've been using GitLab for a several years. Right now is a perfect example of why I use GitLab. I just started a role, and I'm working to improving pull request and CI/CD visibility. This is automatically baked into GitLab. To the point I just copy a template for all my projects. But now I'm writing a bunch of custom integrations, and talking to a number of different third party services. Even with all the extra work it feels less polished than GitLab. With Kubernetes, Serverless, and prometheus metrics integration. Gitlab hand's down provides the best visibility into a release or sprint from what I've seen. There are pain points, but I have very little in the way of complaints. You guys have also been great for the open source community. I got a Gold open source license and am using it for a number of projects. I've converted a number of people to GitLab, now we just need to find places that will let us use it.
- nuritzi 6y ago
  It's great to hear you've had a good experience with the GitLab for Open Source Gold license. I'm the new Sr. Open Source Program Manager at GitLab and I'm helping to revamp the program and also want to find new ways to make GitLab even more value for open source projects and orgs. As a program manager, I'm personally really excited about this year's plans to build out more of GitLab's project management features. I think that once we're able to be more competitive with tools like Jira it will help create more buy-in at companies to adopt a single platform. Let's hope! Thank you for advocating for GitLab among your spheres of influence, and for being part of the GitLab community! We appreciate it!
stevekemp 6y ago
Several people have already mentioned that gitlab is slow, so very slow. I've seen replies in this thread that make it obvious that this is being tracked, and that you're well-aware of it. That said I can't help recalling the last time the topic came up, seven months ago even then it was old-news: https://news.ycombinator.com/item?id=20995889 https://news.ycombinator.com/item?id=20995889 If the site hasn't gotten faster in the past year I think it is obvious that this is not a priority in any real sense. Despite claims to the contrary. Gitlab has a great core-offering, the gitlab runners were wonderful when they came out. But it seems like new features are constantly being piled on top of each release, (time tracking?!) when it might benefit users to step back a little bit and focus upon the core. I can only assume developers get recognition by new-features, not core-improvements.
- sytse 6y ago
  Thanks, I agree we should focus more on loading speed and we'll do so in our second fiscal quarter that starts in two weeks https://about.gitlab.com/company/okrs/fy21-q2/ https://about.gitlab.com/company/okrs/fy21-q2/ The comment you linked says: "We are working hard to improve performance and memory consumption of GitLab. We have two major projects underway, switching to Puma [1] as well as reducing the overall memory consumption of GitLab [2]." The current state is that Puma is now powering all of GitLab.com and we're working on getting it to be the default in Omnibus https://gitlab.com/gitlab-org/omnibus-gitlab/issues/4698 https://gitlab.com/gitlab-org/omnibus-gitlab/issues/4698
enra 6y ago
Doing a campaign/survey where you pay people to compare yourself to your direct competition on your blog, on the areas you chose? Really objective. Also, this topic is about the article linked, not about your survey. As feedback, I would say Github is a better company since it doesn't sink this low on their tactics. They just focus on making their product better.
KayL 6y ago
When will GitLab release the issue edit history feature? It's a very important feature for every group
- samanthalee233 6y ago
  Community advocate here, this released in GitLab 12.9 version https://about.gitlab.com/releases/2020/03/22/gitlab-12-9-released/ https://about.gitlab.com/releases/2020/03/22/gitlab-12-9-rel... https://gitlab.com/gitlab-org/gitlab/issues/32894 https://gitlab.com/gitlab-org/gitlab/issues/32894 Here's the documentation: https://docs.gitlab.com/ee/user/project/issues/issue_data_and_actions.html#16-description https://docs.gitlab.com/ee/user/project/issues/issue_data_an...

earthboundkid 6y ago

Competition is good for the end user, but ISTM that Microsoft bought the biggest player in the space so that they could drown the competition in the bathtub and monopolize the market. It's a smart play from Microsoft's point of view, but FTC should never have permitted the acquisition in the first place and should prosecute them for illegal dumping now.

stevehawk 6y ago
Github and Gitlab are not so important to any market as to warrant federal intervention. Both of them are easily replaced by anyone standing up their own git server. Not to mention the countless other code repository sites / software packages.
- marceloabsousa 6y ago
  I disagree. Github and Gitlab are so much more than just code hosting platforms. Their ability to influence software development is increasing to the point that if both Github and Gitlab suddenly disappear the consequences would be quite dramatic.
- johannes1234321 6y ago
  Moving of isn't easy - thanks to GitHub pages and markdown rendering your tool's homepage is the Git{Hub|Lab|...} page. That page is linked from "everywhere" else and indexed in search engines - all history aside from code is in there (discussions in bug issues and pull requests etc.) getting them out is possible, but all the linkage between commit messages and those might be problematic to migrate - contributors are often only known by their handle on that page, migrating of requires new setup of permissions and mapping of usernames to trust on a social level - there are tons of hooks configured for many projects - as GitHub Actions and GitLab CI gain more and more traction workflows depend on those "Just move the repo" is a fallancy which doesn't work. I have no doubts medium term about Microsoft steering GitHub, but I fear a single entity being so central in the opensoruce world (also consider npm acquisition etc.)
- earthboundkid 6y ago
  Wow, a true HN “I could do that in a weekend”. Good point, all software is trivial and anyone could recreate a website with thousands of man hours behind them in a long weekend.
  - stevehawk 6y ago
    Are we suddenly pretending that Redmine and others don't exist for self hosting?
    - earthboundkid 6y ago
      Yes, there are lots of options in the space, but no one wants to use an option that is 75% as good as Github and still costs more. The only way to gain marketshare is to either get bundled into an enterprise contract (so it doesn't matter if you suck) or be better than Github and still underprice your product. Even Google gave up on their code hosting option because there's no way to get market share without setting money on fire. God bless Gitlab, but if Microsoft keeps supporting Github like this (and the FTC keeps taking long naps), they're going to run out money and die.

pattrn 6y ago

Don't really have the time to do a complete write-up, but for what it's worth I've completely moved my company from GitHub to GitLab within the past year. We found the group and project hierarchy to work very well for organizing our clients and their projects, and we've made extensive use of your CI/CD. The only real complaint I have is about the Auto DevOps feature you released. We're currently using this for a number of smaller projects, and we've found the documentation around customizing deployments severely lacking. We ended up just reading through the Auto DevOps repository since it was clearer and more complete than any online documentation, which eventually allowed us to work through all of the issues we were having. Other than that, it has been a wonderful experience. Thanks for a great product!

emilycook 6y ago
Thanks for the feedback! It's funny you mention the Auto DevOps documentation because we just had our new senior tech writer pick up an issue [1] to completely redo it, so hopefully it'll be more intuitive soon! [1] https://gitlab.com/gitlab-org/gitlab/-/issues/30933 https://gitlab.com/gitlab-org/gitlab/-/issues/30933

7777fps 6y ago

Looking through that comparison, I find it funny that "time tracking" is touted as a feature. My grand-boss might love the idea but the fact that GitHub is missing time tracking is a blessing as a developer. Making developers track their time is hostile. Development is not something you should clock in and out of. A time-box in JIRA or GitHub shouldn't replace management being aware of what their team(s) are working on and how their progress is. It too often turns into a stick to beat developers with. There are all kinds of better metrics by which to hold developers accountable. Tracking time just puts developers off from improving code or refactoring. If you write bad code it's not your time that suffers, it's the next developer who has to work on that section.

emilycook 6y ago
That's interesting feedback, I'll pass it along to the product team, although this is an angle they've probably thought about more than I have. The way we use it isn't really as an accountability metric, more of an estimate that can change dynamically when new problems arise so we can roughly plan out when a feature is going to be released. Granted we don't have a boss who would beat us over the head with that. Thank you for the feedback though I'll make sure to pass it along.
- kirubakaran 6y ago
  > Granted we don't have a boss who would beat us over the head with that. For every boss that wouldn't, there are a hundred bosses that would, with very little understanding of what is even being measured. Sure, the "guns don't kill people, gun users kill people" argument applies, but maybe don't hand people free guns with their milk purchase?
  - emilycook 6y ago
    Oh no I agree, that was just a comment recognizing that my experience is different because I'm in a more ideal situation than other developers are surely dealing with. I still passed along the feedback to our product team!
6y ago

prosim 6y ago

The comparison states that "With GitLab, you get even more features than GitHub Team" and then lists code owners, multiple issue and PR assignees, or standard support. All these features are included in GitHub Team for $4 per month, so this whole section of the blog post is misleading. Also, you may want to point out that GitLab only offers annual billing, so the minimum charge on GitLab is $48. Some of my hobby projects only run a couple of months, so GitHub is the better choice.

emilycook 6y ago
Thanks for the feedback! I passed it on to our content team to see if they want to make adjustments to the blog post. I definitely don't want it to come across as misleading.

shred45 6y ago

Hey, also don't have a time for a full review, but had one comment. I've been a pretty passionate user of GitLab for 2+ years and really loved the industry-leading integrated CI/CD. I have found that page load times on both GitLab and GitHub, however, are pretty bad, with GitLab being the worst. Many administrative tasks, such as logging in -> finding repo -> checking a ci/cd test -> merging / releasing the branch, take 10+ page loads, and each one is quite slow. I ended up moving my personal projects to sourcehut simply because pages are more lightweight and server response times are faster. If GitLab could spend some time reducing the number of pages required for common tasks (not asking for a single-page-app!), and could reduce page load times as much as possible (I know this isn't trivial with Rails), I think that would greatly reduce the friction I feel when using the produce.

emilycook 6y ago
Thank you so much for the feedback! I'm asking around to see if there are any projects open to reduce the number of pages, but I do know for sure that reducing page load times is an issue we're working on. Here is our handbook page that outlines our current metrics and goals, our primary goal is to have a speed index of less than 2 seconds per each page on .com: https://about.gitlab.com/handbook/engineering/performance/ https://about.gitlab.com/handbook/engineering/performance/
- ddevault 6y ago
  I know I'm biased here (full disclosure: sourcehut guy here), but I really hope you'll bring that goal even lower. I recently did a comparison between GitHub, GitLab, and SourceHut on the same "worst-case" page: https://git.sr.ht/~sircmpwn/linux/tree/master/arch/arm/boot/dts https://git.sr.ht/~sircmpwn/linux/tree/master/arch/arm/boot/... https://github.com/torvalds/linux/tree/master/arch/arm/boot/dts https://github.com/torvalds/linux/tree/master/arch/arm/boot/... https://gitlab.com/ddevault/linux/-/tree/master/arch/arm/boot/dts https://gitlab.com/ddevault/linux/-/tree/master/arch/arm/boo... cold cache warm cache git.sr.ht: 1.4s 72K 1.4s 48K github.com: 3.3s 635K 3.0s 317K* gitlab.com: 3.1s 1300K 1.6s 58K+ * Hides half of the files + Only the initial load, it loads a bunch of stuff with JS to keep populating the page afterwards, and has severe performance issues simply using the page (on Chromium, it was straight up unusable on qutebrowser) Even after the page loads, for me it's impossible to use. On a more forgiving "best-case" page, GitLab has poor performance: https://git.sr.ht/~sircmpwn/scdoc/tree/master/src https://git.sr.ht/~sircmpwn/scdoc/tree/master/src https://github.com/ddevault/scdoc/tree/master/src https://github.com/ddevault/scdoc/tree/master/src https://gitlab.com/ddevault/scdoc/-/tree/master/src https://gitlab.com/ddevault/scdoc/-/tree/master/src cold cache warm cache git.sr.ht: 296ms 28K 198ms 4K github.com: 572ms 360K 629ms 36K gitlab.com: 1310ms 1311K 1110ms 16K You should definitely make performance a core focus IMO.

phoe-krk 6y ago

Is it possible to submit replies via Fediverse or mail? Asking since I do not have a Twitter account and do not want to create one.

Normal_gaussian 6y ago

I don't have a blog to blog on yet, and you are likely looking for that to get some positive backlinks, but here are my two cents anyway. I use both for work - and gitlab by preference: * On the whole they are now close enough that I don't worry about the choice * Both are slow. Silly slow. A 2 second target for page loads is horrific. Jumping around a file structure and exploring blame is really really painful; but 90% of the time I'm on the pipelines page and its so so so slow. Its actually faster for me to have my pipelines webhook a private server for a faster dash. * GitLab is better for CI/CD. Easier, more sensible. I use it all the time; I set new clients up on it. * Gitlab is better for k8's - several clients use it and love it. * Search sucks on them both. They both give a paginated list when what I always want is a place in repo / filetype / etc. filter, post initial search (i.e, I'm looking for loadModule in webpack, I want to ignore tests (when I didn't know which was the test folder before searching), and jump between definition and usage, as well as find out if there is any documentation. Its not worth doing each individually. I want all at once) * API's are really slow. GitLab is probably worse here. My default webpage (localhost home page) is a dashboard of quick links and widgets. One of those widgets shows my failing pipelines. It takes 6 seconds on a good day. I bypassed it (as above) to let me be more responsive. I didn't have to bother bypassing it w/GitHub * On my NAS I maintain images of GitLab hosts and backups of all my repos. I have an image of the self-hosted gitlab we had at a previous (it closed) company. Being able to fall back to self-hosted is the oft-touted godsend, but being able to restart a retired self-hosted has literally made me and the others involved several thousand each (twice old clients have wanted a one off job. GitLab is the core of testing and deploying infrastructure).

kennyGitLab 6y ago
GitLab Product Leader here - > * Both are slow. Silly slow. A 2 second target for page loads is horrific. Jumping around a file structure and exploring blame is really really painful; but 90% of the time I'm on the pipelines page and its so so so slow. Its actually faster for me to have my pipelines webhook a private server for a faster dash. Agreed - and we're working on performance improvements for GitLab.com. Do you use GitLab.com or a self-managed instance? > * GitLab is better for CI/CD. Easier, more sensible. I use it all the time; I set new clients up on it. Thanks - I'll give the feedback to the teams to keep up the good work. We do focus on sensible defaults and easy setup. > * Gitlab is better for k8's - several clients use it and love it. Awesome to hear, I have some heritage with this part of the product so I'm glad you love it. > * Search sucks on them both. They both give a paginated list when what I always want is a place in repo / filetype / etc. filter, post initial search (i.e, I'm looking for loadModule in webpack, I want to ignore tests (when I didn't know which was the test folder before searching), and jump between definition and usage, as well as find out if there is any documentation. Its not worth doing each individually. I want all at once) We have a recent integration with SourceGraph, have you tried that out? https://docs.gitlab.com/ee/integration/sourcegraph.html https://docs.gitlab.com/ee/integration/sourcegraph.html > * API's are really slow. GitLab is probably worse here. My default webpage (localhost home page) is a dashboard of quick links and widgets. One of those widgets shows my failing pipelines. It takes 6 seconds on a good day. I bypassed it (as above) to let me be more responsive. I didn't have to bother bypassing it w/GitHub Uggh - I'm sorry. I don't quite understand your reference to a default webpage and widgets. Is it pulling from GitLab APIs to give you a dashboard of your development work? > * On my NAS I maintain images of GitLab hosts and backups of all my repos. I have an image of the self-hosted gitlab we had at a previous (it closed) company. Being able to fall back to self-hosted is the oft-touted godsend, but being able to restart a retired self-hosted has literally made me and the others involved several thousand each (twice old clients have wanted a one off job. GitLab is the core of testing and deploying infrastructure). I didn't follow this one explicitly either. I'm glad you've got backups, are you suggesting GitLab needs some improved restore capabilities from backups?

soulnothing 6y ago

I've wanted to do a deep dive into Github vs Gitlab for projects. But I'm a bit hesitant to have that on my blog. Unfortunately most places I've been pushing for anything other than Github is not well received. That being said I've been using GitLab for a several years. Right now is a perfect example of why I use GitLab. I just started a role, and I'm working to improving pull request and CI/CD visibility. This is automatically baked into GitLab. To the point I just copy a template for all my projects. But now I'm writing a bunch of custom integrations, and talking to a number of different third party services. Even with all the extra work it feels less polished than GitLab. With Kubernetes, Serverless, and prometheus metrics integration. Gitlab hand's down provides the best visibility into a release or sprint from what I've seen. There are pain points, but I have very little in the way of complaints. You guys have also been great for the open source community. I got a Gold open source license and am using it for a number of projects. I've converted a number of people to GitLab, now we just need to find places that will let us use it.

nuritzi 6y ago
It's great to hear you've had a good experience with the GitLab for Open Source Gold license. I'm the new Sr. Open Source Program Manager at GitLab and I'm helping to revamp the program and also want to find new ways to make GitLab even more value for open source projects and orgs. As a program manager, I'm personally really excited about this year's plans to build out more of GitLab's project management features. I think that once we're able to be more competitive with tools like Jira it will help create more buy-in at companies to adopt a single platform. Let's hope! Thank you for advocating for GitLab among your spheres of influence, and for being part of the GitLab community! We appreciate it!

stevekemp 6y ago

Several people have already mentioned that gitlab is slow, so very slow. I've seen replies in this thread that make it obvious that this is being tracked, and that you're well-aware of it. That said I can't help recalling the last time the topic came up, seven months ago even then it was old-news: https://news.ycombinator.com/item?id=20995889 https://news.ycombinator.com/item?id=20995889 If the site hasn't gotten faster in the past year I think it is obvious that this is not a priority in any real sense. Despite claims to the contrary. Gitlab has a great core-offering, the gitlab runners were wonderful when they came out. But it seems like new features are constantly being piled on top of each release, (time tracking?!) when it might benefit users to step back a little bit and focus upon the core. I can only assume developers get recognition by new-features, not core-improvements.

sytse 6y ago
Thanks, I agree we should focus more on loading speed and we'll do so in our second fiscal quarter that starts in two weeks https://about.gitlab.com/company/okrs/fy21-q2/ https://about.gitlab.com/company/okrs/fy21-q2/ The comment you linked says: "We are working hard to improve performance and memory consumption of GitLab. We have two major projects underway, switching to Puma [1] as well as reducing the overall memory consumption of GitLab [2]." The current state is that Puma is now powering all of GitLab.com and we're working on getting it to be the default in Omnibus https://gitlab.com/gitlab-org/omnibus-gitlab/issues/4698 https://gitlab.com/gitlab-org/omnibus-gitlab/issues/4698

enra 6y ago

Doing a campaign/survey where you pay people to compare yourself to your direct competition on your blog, on the areas you chose? Really objective. Also, this topic is about the article linked, not about your survey. As feedback, I would say Github is a better company since it doesn't sink this low on their tactics. They just focus on making their product better.

KayL 6y ago

When will GitLab release the issue edit history feature? It's a very important feature for every group

samanthalee233 6y ago
Community advocate here, this released in GitLab 12.9 version https://about.gitlab.com/releases/2020/03/22/gitlab-12-9-released/ https://about.gitlab.com/releases/2020/03/22/gitlab-12-9-rel... https://gitlab.com/gitlab-org/gitlab/issues/32894 https://gitlab.com/gitlab-org/gitlab/issues/32894 Here's the documentation: https://docs.gitlab.com/ee/user/project/issues/issue_data_and_actions.html#16-description https://docs.gitlab.com/ee/user/project/issues/issue_data_an...