EDIT: I'm setting up a private repo for an upcoming project, and I'd like to run the issue tracking through some git service, potentially scaling to include a Kanban Board. Not sure if it's gonna be just me or other devs. This looks promising:
http://kanban.leanlabs.io/
I've set myself the challenge of being as financially prudent as humanly possible, especially with this project, as it is an extremely low budget.
If Gitlab can offer free private accounts, with a couple cool features thrown in on the side, why shouldn't I use it?
Which do you use? Why not the other?
PS – I'm not from Gitlab, I'm just some hacker trying to lock up his stack. :)
Some benefits for GitLab.com, in my opinion: GitLab.com has free public and private repos, only limit is the repo size (max 10GB, for comparison the Linux repo is ~1.5GB). Also includes completely free CI :) Plus everything is out in the open, and CE is entirely open source!
Regarding performance, we've gotten that feedback from a lot of users, and we're working very hard on improving it[1][2][3]. I've personally been working a lot on decreasing the page size, chopping off a ton of extra unnecessary assets to make things download and parse faster.
Would be happy to answer any other questions you have! Hopefully this doesn't sound like too much of a sales pitch ^_^
[1]: https://gitlab.com/gitlab-org/gitlab-ce/issues/19273#note_12...
$7 for a GitHub account with unlimited private projects is a pretty good deal, especially compared to their previous pricing tiers. I also think the experience of using one website for most open source projects as well as private projects is better.
How can we make issue navigation better? By the way, what do you think of the recent menu redesign? https://about.gitlab.com/2016/06/06/navigation-redesign/
What we hear most frequently a reason for switching is the in the integrated CI, CD, and container registry. The GitHub importer will import your repo, issues, PRs, milestones, labels, and wikis http://docs.gitlab.com/ce/workflow/importing/import_projects...
Full disclosure: I'm Head of Product for Bitbucket. LMK if you want to chat, a link to my calendar is in my HN profile.
[0]: https://bitbucket.org/integrations/cloud [1]: https://marketplace.atlassian.com/plugins/com.comalatech.bit... [2]: https://marketplace.atlassian.com/plugins/bucketboard/cloud/...
Both gitlab and bitbuckets source code browsing is slow and a little clunky. GitHub's source code browsing is definitely the best.
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 performance https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&sor...
Regarding web performance, these last days we had really good progress: https://gitlab.com/gitlab-com/infrastructure/issues/193#note...
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.
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.
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
In fact, it's a part of our code review/pull request functionality, therefore "it just works".
Coming up for air after a deep dive with Keystone.js – as you all have invested your time, I owe you an answer:
I’ve decided to go with GitLab going forward. It’s free, has integrated well with my team, runs itself in the cloud with the option of being run locally, and has some super promising stuff in the pipes. I’m excited to see what else it can do!
Before I get to the runners-up: massive thanks to everyone who participated here. This is a super cool community that I’m lucky to be able to tap into; and watching various well-thought arguments and rockstars give their two cents has been a real treat.
Bitbucket is the service that, unfortunately, I always seem to hear all of about 15 minutes too late. I see Bitbucket about on par with Github between what they offer – the biggest thing that it has going against it, then, is its lack of proliferation. Perhaps it’s that Github locked up their UI earlier, perhaps it’s just what I’ve been grandfathered into. But all too often, it proves to be the path of least resistance for a significant enough of the dev population – and that’s a good sign they’re doing something right.
Having said that, I would love to see this balance shift. :D Please, prove me wrong!
Rhodecode is definitely something to keep your eye on. Squabbles aside, it looks like they have a lot of really dedicated people working on something that looks extremely promising. Please keep fighting the good fight!
Again, endless thanks to everyone who jumped in here. I’m on skype @mike.of.the.jungle, if you’d like to say hi.
I am very glad to hear that you decided to go with GitLab. We are trying hard to make it better and open for you. Thank you for your support.
I have not really tried GitLab's hosted offering, I have a couple repos up there, but nothing extensive.
Have you considered a VPS with Gogs? It's super lightweight and easier than snot to setup.
Funny tho that they host their own code on GitHub. Is that just because they don't want to pay for hosting? (That's sensible.)
I'd probably still pick Gogs though... we're not a big team and many of the features provided by GitLab and RhodeCode are above and beyond what we require. Basically, our implementation is me finding a way to force version control onto a team that, for some reason, wasn't using any form of VCS at all.
[0]: https://blog.bitbucket.org/2015/10/01/contributing-to-git-lf...
That should solve the Sidekiq restarts and the upgrades https://twitter.com/johann_sonntag/status/745791831225544704
Happy to engage further if you email me. scott <at> atlassian.com.
Scott Farquhar, Atlassian CEO
#1 It plays nicely with existing trackers and CI tools.
#2 RhodeCode fully supports Git, Mercurial & SVN (hence no VCS lock-in).
So now my answer is self-hosted Gitlab.
If you feel that Gitlab.com is slow, give self-hosting a try; the omnibus packages are quite easy to install/upgrade and it's quite fast even with many dozens of repositories on a 2GB DO instance.
Since RhodeCode is open source, it can be tailored to one's own needs.
I have not tried Gitlab so I won't comment on that. I will say, however, Github has put a lot of work into the pull request interface and being able to examine code. This matters a lot more when you are working with a team (though it assumes you know how to take full advantage of it). I'd look at Gitlab through that lens, and if you are working solo, the cheaper solution is probably OK.
Also, gitlab's CI system is attractive and being able to run our own runners in our own environment (we currently used an outsourced CI system.)
We're also doing it because Github enterprise is too expensive, and we want to rely on less external dependencies in our environment.
With no effort we are managing dozen of projects and now we are in love with CI (and OpenShift)
We want to start using HUB again as mirror (still need to understand how...) but no plan to leave GitLab.
Here the feedback
. Easy to use . Easy (apt-get) to update . Nice to manage . Yours . Same flow as git hub if you use it as git repository...
RhodeCode CE is free, self-hosted & open-source, with code review tools, user management, and automations. It takes ~5mins to get your own instance up and running. Most of RhodeCode users have secure, behind-the-firewall repositories, where conventional tools are not enough. Seems like a good fit for your case.
I realize you are using Git, however if you collaborate with an external partner or customer, RhodeCode supports Git, Mercurial & SVN repos _simultaneously_ . See, should you decide to migrate from one VCS to another, we got you covered :)
Besides, we have a great engineering culture, hence performance has never been a problem (e.g., we use Elasticsearch for full-text code search). Ask our users on #Slack: https://rhodecode.com/join
> The company claimed to have 100% of the copyright in RhodeCode, even though patches had been accepted from others
You can read more about why RhodeCode went back to open source (AGPL) here: https://rhodecode.com/blog/113/rhodecode-goes-open-source
Check out https://bitbucket.org/product/pricing as well.
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/infrastructure/issues/59
We'll keep improving over the next few months, lots of work still to do.
With regard to UI/UX improvements, I'll have to check it out and see how much it's changed since last time :-)
Github - I use it for public projects because, it's the most popular site so larger pool of people.
Gitlab - It's free to put your private repos here so, this is where I store all my infrastructure code.
GitHub meets my needs, and I'm a happy $7/mo. customer. :-)
- Open Source
- Frequent updates, new features
- CI built in
- No drama
- Free
Github:
- Faster than Gitlab
I'm pretty sure Gitlab wins big time, I switched and never looked back.
On the other hand, Phabricator is a solution that contains a much more variety of features, which might be suitable to certain teams.
One of the smaller teams used this, and it seemed to be more helpful than harmful:
https://www.visualstudio.com/products/visual-studio-team-ser...
Gitlab works, and is decent, but only in certain circumstances.
Pay for SaaS products wherever you can and makes sense. Only build/host your own things that deliver you business value.
You have a person who wants to contribute code to you open source project, but that person is stymied by requiring an account on a service other than GitHub.
What kind of people are you expecting to be doing drive-by code contributions and what kind of code quality are you expecting from them?
I've made a few OSS contribs that were fork, clone and edit locally (or edit online in one case), push, test, pull request.
That was all, they took ~20 minutes, if that. Adding in "create an account", "figure out the new UI's method of forking/pulling", and "link myself to another random webservice that I'll only use once" is too much friction, I might spend as much time setting up the account as actually making the edit.
Sure, if I'm planning to become a contributor to a large project (like, say python, which isn't on gh), I'll go ahead and make an account on the bugtracker and join the mailing list and learn how the hell mercurial works. That's fine if I expect to make 10+ commits to a project and really delve deep into it. But most projects aren't big. Most projects aren't that interesting. OSS thrives on people fixing the one bug they encounter (seriously, look at the bus number of major projects). Adding friction in the process is bad for that software.
I can't recommend them for anything serious.
