Live data from Hacker News

Ask HN: GitHub vs. Gitlab?

news.ycombinator.com

51–60 of 113 posts

Re: Ask HN: GitHub vs. Gitlab?

#51
post #24
post #8

Gitlab's servers have been slow in my experience. Sometimes taking 10-15 seconds to push up a new commit. I got tired of waiting and moved everything back to bitbucket. Both gitlab and bitbuckets source code browsing is slow and a little clunky. GitHub's source code browsing is definitely the best.

github cheats for performance. our github enterprise will not bother try show diffs on some pull requests if you changed more than a hundred lines or so. very worthless. my workflow now is to always check the diffs locally because i don't trust theirs. never used gitlab or bitbucket a lot so i don't know if this treachery is there too.

Bitbucket engineer here!

In Bitbucket Cloud - i.e. bitbucket.org - we cap the diff size for pull requests at 10000 lines.

In Bitbucket Server we also cap the number of lines in a particular diff at 10000 by default, but you can override this number[0], along with all other timeouts and thresholds with our various configuration properties. One of the engineering values of the Server team is "no hardcoded constants" - so you can configure basically any property that you like to suit your particular deployment.

Both Bitbucket Server and Cloud also generate a subtly different - and in our opinion more correct - diff than you'll find in GitLab and GitHub. Bitbucket actually creates a hypothetical merge commit between your two branches and shows the diff between it and the tip of the target branch. This means we can nicely render merge conflicts in the UI, and show how your target branch will actually be affected by the merge (rather than just the changes on the source branch). I wrote an article that discusses our merge algorithm in more depth[1] a little while ago.

[0]: https://confluence.atlassian.com/bitbucketserver/bitbucket-s... [1]: https://developer.atlassian.com/blog/2015/01/a-better-pull-r...

edit: correcting my previous statement on diff sizing in Bitbucket Cloud

Re: Ask HN: GitHub vs. Gitlab?

#52

Earlier quoted context omitted.

We put a lot of thought in our most recent release to improve the UI/UX, so some of your problems with that may have been resolved since you last used GitLab. As for performance, we've started treating speed as a priority, and we've been tracking progress in various issues: https://gitlab.com/gitlab-org/gitlab-ce/issues/19273#note_12... https://gitlab.com/gitlab-com/operations/issues/42 https://gitlab.com/gitlab-com/…

Yes! I've been seeing a lot of great improvements being added to GitLab recently. I'm intrigued to see what the future holds, and could definitely see myself switching in the near future. With regard to UI/UX improvements, I'll have to check it out and see how much it's changed since last time :-)

If you have specific issues with the UI/UX or find any bugs, feel free to open an issue and mention me (@connorshea) :)

Personally the performance issues have been super annoying for me when using GitLab.com, so I've been doing what I can removing unnecessary assets and things, making the page size smaller.

One huge improvement recently was speeding up the Files view, I used to actually avoid it because it was way too slow, really bad experience.

We all use GitLab.com every day to develop GitLab, so we're very much aware of the problems!

Re: Ask HN: GitHub vs. Gitlab?

#53
I haven't used GitHub a ton, but GitLab is really crappy in my experience. I'm constantly frustrated by the UX. CVSweb and Trac do a better job, and did so 10 & 15 years ago. I've also used BitBucket quite a bit; it's not great, but it's a ton better than GitLab.

Re: Ask HN: GitHub vs. Gitlab?

#54
post #17

Earlier quoted context omitted.

You're right, we have to do better on performance. We solved most of the time waiting when pushing a new commit, see the API timings slide on https://www.scribd.com/doc/316471059/GitLab-Infrastructure-2... The web interface is still slower than we like. We've doubled the team of performance engineers and we're making progress, see https://gitlab.com/gitlab-com/infrastructure/issues/59 and all issues labeled with perf…

At a high level, what are the major areas where you face performance issues? Does the choice of RoR play a part in performance problems? Can performance be improved by deploying more servers? PS: I really enjoy using Gitlab, and would be ready to replace Github with Gitlab in my workflow if the performance improves.

My understanding (as a frontend engineer, so I'm not as intimately familiar with the problems as some others are) is that the biggest bottleneck at this point is with the file system.

We're working on switching to CephFS which looks very promising. See the relevant issue for more info: https://gitlab.com/gitlab-com/operations/issues/1

I can get someone from the backend performance team to comment too if you'd like :)

Re: Ask HN: GitHub vs. Gitlab?

#55
I'm using Gitlab right now, and honestly I wish I'd chosen GitHub instead. Self-hosted Gitlab requires maintenance (Sidekiq randomly dies, needs manual restart), upgrading is a pain, and (for me) when I tried exporting my projects from self-hosted Gitlab to Gitlab.com tbe import failed with a "unable to decompress" error on Gitlab.com! I'm too tied to Gitlab now with all the wiki pages, issues, etc. but I'm left disappointed with these problems I've had.

Re: Ask HN: GitHub vs. Gitlab?

#56

Earlier quoted context omitted.

At a high level, what are the major areas where you face performance issues? Does the choice of RoR play a part in performance problems? Can performance be improved by deploying more servers? PS: I really enjoy using Gitlab, and would be ready to replace Github with Gitlab in my workflow if the performance improves.

My understanding (as a frontend engineer, so I'm not as intimately familiar with the problems as some others are) is that the biggest bottleneck at this point is with the file system. We're working on switching to CephFS which looks very promising. See the relevant issue for more info: https://gitlab.com/gitlab-com/operations/issues/1 I can get someone from the backend performance team to comment too if you'd like :)

[deleted]

Re: Ask HN: GitHub vs. Gitlab?

#57

I use Bitbucket for private projects. It comes with a little issue tracker, although I just use a Google doc for task tracking.

Have you tried out Atlassian's JIRA software? It's free for up to 5 users I think.

My last corporate job used JIRA. I'm convinced that smaller teams will be much more productive with a looser issue/task tracking mechanism, like a Google doc or Trello board.

One of the smaller teams used this, and it seemed to be more helpful than harmful:

https://kanbanflow.com/

Re: Ask HN: GitHub vs. Gitlab?

#58
post #11

Thanks for considering GitLab. The different scrum boards for GitLab are detailed on https://about.gitlab.com/applications/#scrum-boards For GitLab 8.11 (August 22) we're planning to ship a kanban board with GitLab itself, see https://gitlab.com/gitlab-org/gitlab-ce/issues/17907 What we hear most frequently a reason for switching is the in the integrated CI, CD, and container registry. The GitHub importer will import…

Bitbucket engineer here. Not to derail, but since Bitbucket has been brought up a few times in this thread and we're talking differentiating features this seems relevant: Bitbucket also has native Docker-based CI/CD in the form of Bitbucket Pipelines[0].

[0]: https://bitbucket.org/product/features/pipelines

Re: Ask HN: GitHub vs. Gitlab?

#59

http://www.phacility.com also known as phabricator is really nice. you should give it a try.

Totally agree, to me Github and Gitlab are so similar that there really is no point in arguing which one to use, just pick either one and you should be okay.

On the other hand, Phabricator is a solution that contains a much more variety of features, which might be suitable to certain teams.

Re: Ask HN: GitHub vs. Gitlab?

#60
post #12

I'd just gitlab because it's open source. You could run your own gitlab servers if you wanted. You don't have to worry about vendor lock in unless you use the paid features.

One of the nice things about Git is that it's an extremely portable data format, so vendor lock-in between Bitbucket, GitLab & GitHub isn't too big a deal. There may be a little project metadata that needs to be migrated using an importer, but your source code will always be inherently transferable. It's one of the big reasons Atlassian decided to partner with GitHub on Git LFS[0] rather than pursue our own solution: we didn't want to reduce Git's portability by creating multiple competing standards for large file storage.

[0]: https://blog.bitbucket.org/2015/10/01/contributing-to-git-lf...

Post reply on HN