Gitlab More Than Doubles Valuation to $2.75B Ahead of Planned 2020 IPO

Post by skrebbel » Tue, Sep 17, 2019, 4:45 PM UTC

jakeinspace wrote: post #19

cj wrote: post #3

Question to current Gitlab users: Why do you use Gitlab instead of Github? What are the killer features that make it worth switching to?

My employer uses gitlab for most internal projects because of ITAR and other legal restrictions (aerospace). No external hosted services allowed, except obviously for released open source code.

Post by stevekemp » Tue, Sep 17, 2019, 4:55 PM UTC

dsumenkovic wrote: post #84

0xffff2 wrote: post #69

Earlier quoted context omitted.

Sluggish and nearly unusable describes every experience I have ever had with GitLab.

Thanks for the feedback. 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]. You can follow along on some of the progress we are making in each release post in the "Performance Improvements" section. For 12.2 you can see we had 58 MR's related to performance. [1] - http…

Post by auspex » Tue, Sep 17, 2019, 5:00 PM UTC

banachtarski wrote: post #169

ryanmcbride wrote: post #157

At my last job Gitlab was in the stack and I had never used it before so I was expecting it to be a real pain. It was actually a perfectly pleasant experience. I don't think it'll make me leave Github but I put them at the same level now. Merge Requests never felt right saying over Pull Requests, even though it's more descriptive of what's actually happening.

I'm being pedantic here, but the reason I prefer pull is because it feels more general than a "merge," which to me precludes a fetch/rebase. I guess you could consider it a merge -ff-only, but in a mergeless-master workflow, "merge request" felt awkward.

Post by throwaway77384 » Tue, Sep 17, 2019, 5:02 PM UTC

pm90 wrote: post #37

Kudos to the team. While my current workspace is tied to GitHub, I will most certainly switch to Gitlab given the option to. Why? Only one reason: GitHub support is fucking horrible. It’s insanely bad, even for paying enterprise customers. Open a support ticket, you will get some superficial pointers to documentation, and then be completely ignored. Their Product team is the absolute worst too. There are so many thin…

Post by emilycook » Tue, Sep 17, 2019, 5:09 PM UTC

stevekemp wrote: post #174

dsumenkovic wrote: post #84

Earlier quoted context omitted.

Thanks for the feedback. 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]. You can follow along on some of the progress we are making in each release post in the "Performance Improvements" section. For 12.2 you can see we had 58 MR's related to performance. [1] - http…

I've heard this from gitlab employees before. Every. Single. Release. For. The. Past. Two. Years. At some point it seems clear that despite statements to the contrary the speed of the instance, and the resource consumption just cannot be a concern. I'd rather the core was speedy and resource-appropriate than see additional half-working features bolted on non-stop, while bug reports languish.