Hacker News Reader

Comment by sytse | Hacker News Reader

What can we improve in GitLab to make it better? Did the install take too long? Did you try our Omnibus packages or a source install?

View on HN

I tried installing the omnibus and from source. Both times I could not get it completely working. On CentOS 5.3 x64. I eventually got everything but git commits working over ssh, but I quit trying to get that working after it looked like I had to give up port 22.

I was just installing installing for evaluation and hopefully our sys admins will do the final install.

Gogs was just 'install Go', 'run binary', 'link to database/git ssh user' done.

I'm sorry to hear you had problems installing GitLab. Maybe it was an SE Linux problem? https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/doc... You can configure an alternative ssh port for the Omnibus packages in https://gitlab.com/gitlab-org/gitlab-ce/blob/30e4d3ce9a18340... If you encourter problems again please email support@gitlab.com and include a link to this comment.

I think I remember that most of my issues were SE Linux related. We liked Gitlab and are going with it, I just personally found Gogs a lot easier and simpler to get going and the missing features weren't that important to us. Thanks for the helpful links.

Thanks for the feedback. Glad to hear you're going with GitLab. If you have any idea's how to improve our SE Linux experience please let me know.

Why did you have to install Go?

I've tried and failed three times to get Gitlab to send me a sign-up email. I can't get it to work. I can't figure out how to disable the confirmation emails either. I'd be using a self-hosted Gitlab to try to fix the speed issues but because of this issue, I cannot. So, instead, I'm a refugee on your public service until I convince my coauthor to eat another repository migration to a private Gogs instance.

I got gogs working in 5 minutes like OP said.

Also Gogs is >>>>>>>>>>>>>>>>>>>>>> faster. It baffles me that I can be pushing an initial commit to an empty repository and my terminal will hang for 10-15 seconds. What's going on with that?

Thanks for the feedback. Aroch posted a good Mailgun config in https://news.ycombinator.com/item?id=11374883 but your post gave me the idea to disable confirmation emails by default https://gitlab.com/gitlab-org/gitlab-ce/issues/14684

I'm not sure what is up with the initial commit issue you describe and made an issue to investigate https://gitlab.com/gitlab-org/gitlab-ce/issues/14685

Thanks again!

If you're self-hosting, I would use mailgun with the below config in your /etc/gitlab/gitlab.rb

https://gist.github.com/ar0ch/b33a9232776504bd83ac

I spent an hour or so with GitLab and disliked the amount of whitespace. I shouldn't have to scroll so much to see what's in a repo.

</minor-annoyance>

Thanks for the feedback. I added you comment to https://gitlab.com/gitlab-org/gitlab-ce/issues/14548

We use JIRA so by default we are shoe-horned into Stash/Bitbucket. I've used gitlab on my own and found it beyond easy to use and very reliable. I see gitlab people posting every once and a while on hacker news and they seem very interested in improving the product overall. Contrasted with Atlassian who seems to have no interest in improving their core product and only enabling new revenue-driving products or costly extensions. So thanks.

Glad to hear you like GitLab. Did you know that we merged our excellent JIRA support into the open source GitLab CE? See http://doc.gitlab.com/ce/project_services/jira.html

The things I miss the most using Gitlab vs github are the instantaneous merges and the syntax highlighting within diffs when reviewing a MR. I'm on an old-ish version of gitlab though and it's running on a single VPS.

We have syntax highlighting within diffs since 8.4 https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/2109 so please consider upgrading.

I don't understand what you mean with instantaneous merges, did merges seem faster in the past? We do have a feature that allows you to merge when the build is successful, saving many people lot of time http://doc.gitlab.com/ce/workflow/merge_when_build_succeeds....

We're on 8.1 I think. We are running a largeish C# project with largeish diffs; when I click "merge" the app spins for a good few seconds or more before completing the merge. Don't think I've ever seen that sort of delay on github. I wonder if you could pre-merge in a separate system branch then do some git magic to rearrange them once the user actually clicks merge?

Pre-merging when you look at the merge request is an interesting idea. Technically that will work but it will add complexity and use more resources. Feel free to make a feature request for it. At this point I think there is lower hanging fruit we can pick to improve performance.

I wouldn't prioritize it if I were you either ;)

Thanks for understanding :)

I'd like to run Gitlab on FreeBSD and never could get it working. So for my side work projects where all the hosting is on FreeBSD I'm using Gogs. A port would fix that.

Thanks for the feedback. All the FreeBSD support right now is unofficial https://github.com/gitlabhq/gitlab-public-wiki/wiki/Unoffici... and https://gitlab.com/gitlab-org/gitlab-recipes/tree/master/ins...

We would love to support it officially but we do need customers to express the same. We're currently talking to a client that might make this happen, so I'm hopeful.

Reply on news.ycombinator.com