[coldcode]

At where I work we use Github Enterprise, which costs way more than Gitlab Enterprise, is not scalable, and barely cares about enterprise customers like ourselves. Gitlab on the other hand is much cheaper, is highly scalable, runs in AWS, and is responsive to requests. Ultimately to make it as a business you need to provide what the customer wants and is willing to pay. Github never did.

[foobarbazetc]

We switched from GitHub Enterprise to BitBucket Server several years ago and are pretty (80%) happy with the decision. Saved an absolute truck load of money.

The only issue with BitBucket Server is that it (inexplicably) does not have a commit compare view.

https://jira.atlassian.com/plugins/servlet/mobile#issue/BSER...

This is such a massive oversight I have to conclude Atlassian themselves don’t use this product.

It annoys us but not enough to pay GH.

We don’t like GitLab as it was slow when we tested it and the UI wasn’t designed as nicely as the other two (tbh it looks like it was designed by programmers). Something about GitLab feels off and I don’t really know what it is.

If MS changes the cost structure of GH Enterprise we’d probably switch back (haven’t looked into how well it integrates with Jira etc recently).

[gm-conspiracy]

Also, their Sourcetree offering for Windows is quite nice, but the OS X version has big problem with git-flow.

You can tell it is two very different teams working on it.

Atlassian is now like the Cisco of late 90s an early 2000s, an amalgamation of disparate companies' technologies under the umbrella brand.

[mercutio2]

There are many things I find frustrating about BitBucket Server (it’s super slow, for one, it’s insistence on clobbering commit strings during merges is the biggest), but I’ve never wanted a commit compare view; I don’t even know what that is.

Care to explain what you would use it for?

[foobarbazetc]

Just seeing all the commits/changes between two commits.

So with GitHub Enterprise when you push multiple commits, the webhook sends a “compare” URL which is a handy look at everything that got pushed.

It’s not possible to do the same thing with BitBucket Server.

You can compare two tags and get the same view. Or two branches. But not two commits.

[Xaena]

I'd be interested to hear about the slow behavior you're seeing. There are some tips and tricks for improving that.

[mercutio2]

Generally speaking, I have found Atlassian’s tools don’t scale well to megacorp usage. When there are thousands to tens of thousands of users connecting at peak times, stuff just gets extremely slow. Noticeably slower than when we all put up our own team-level Phabricator instances, although I’m obviously not adjusting for Phabricator downtime when inevitably the unofficial team sysadmin went on vacation and the server fell over.

I’m sure people involved in infrastructure are working on making this better, but I don’t have any visibility into that layer.

[Xaena]

From a speed standpoint, I'll say the obvious thing, "it's architecture dependent".

For thousands to tens of thousands of users, most folks need data center with 1+n nodes (w/ larger diminishing returns at 8 nodes). There's a few tips and tricks with that, like pointing CI/CD tools to a smart mirror instead of the primary instance and only mirroring specific build projects. Putting smart mirrors in the same physical location as a primary instance could also help reduce the impact of CPU-intensive requests like git fetch or clone.

Another common issue is apps/plugins. Bitbucket 5.9 added a way to get app diagnostics so infra folks can see if there's a long-running process or other weirdness. Vanilla Bitbucket needs about a 1gb heap (java) and with apps, you want around 4gb (give or take).

If you want a longer read to share, this still has some good info despite being 2~ years old: https://developer.atlassian.com/blog/2016/12/how-we-built-bi...

[u801e]

> The only issue with BitBucket Server is that it (inexplicably) does not have a commit compare view.

Github and Github Enterprise also fail to provide this view. They do provide a compare view for the triple-dot notation (git diff <commit1>...<commit2>) which actually compares the merge-base of commit1 and commit2 with commit2. It's not possible to do the equivalent of git diff commit1..commit2 in the web interface.

[pm90]

> If MS changes the cost structure of GH Enterprise we’d probably switch back (haven’t looked into how well it integrates with Jira etc recently).

Given that they acquired GH mostly for the Open Source parts, I wouldn't bet on that :/. Enterprise was Github's way of making money and that incentive is kinda reduced, if not eliminated entirely.

[Xaena]

Atlassian employee that works with/on Bitbucket here.

We're working on improving that experience. I'd keep a lookout on the next few releases.

[FeloniousHam]

I was on a team evaluating Github and Gitlab for a large corporation (>10000 seats). Github was multiples more expensive than Gitlab, and unwilling to even come close on a counter offer.

I am a fan of Github (and can appreciate their reluctance to deal with Enterprise headaches), but Gitlab was much more engaged and committed to win the contract. Github didn't seem to care whether they got it or not.

[singingfish]

There are quite a few things about gitlab that smell of amateur hour with the way it's put together, but on the whole it's a really good product and I like that enough to make it usable is free open source, and the CI stuff is much nicer than any other I have used (although the way we've put it together, we've hit its limitations a bit).

[2RTZZSro]

You accuse Gitlab of "quite a few [problematic] things" but do not put forward even a single one of those.

[singingfish]

I was on mobile and on my way to bed :P. Lots of page refresh related problems, and likes to exhaust memory from time to time are the two standouts.

[mikekchar]

Have I missed something here? Why are you with Github and not Gitlab?

[blattimwind]

Generally speaking, the set of people who live with the consequences of a decision is not the same set of people who made said decision.

[cease]

The commenter may not be in a position to make the decision to switch. It's also possible that changing would incur high switching costs - although I'm not sure what they'd be.

[coldcode]

We have both, however some teams predate Gitlab option and corporate inertia, politics and a lack of time keep those teams from switching. In a huge company changing anything can be a major pain in the ass.

[wastedhours]

Corporate inertia?