Hacker News Reader

Comment by glandium | Hacker News Reader

Just for this, I'm tempted:

One issue that was raised several times was the ability to not create merge commits. In GitLab you can, as an alternative to the merge commits, use fast-forward merges or have merge requests be automatically rebased.

The main thing keeping me from actually doing it is the network effect... and this:

Disadvantages

Right now GitLab.com is really slow and frequently down. This is because of fast growth in 2015.

View on HN

Just wanted to point out the disadvantage statement came from https://about.gitlab.com/gitlab-com/

At GitLab we are honest about issues, and transparent about what we're working on. HTH!

Thank you for your transparency, it means a lot! :)

I think taking the conservative approach of not re-writing history (--no-ff) is appropriate for a service like github. It is easy to ff merge PRs from the command line.

Very true, I think they are working very hard on improving the experience this quarter. Front page of HN probably does not help either. :)

Thanks! We're very glad to be on the front page and hopefully get more people contributing and discussing features. GitLab.com is now at a size were the HN crowd doesn't make a dent. But the HN crowd is very important because they are frequently active contributors. We are trying to solve the speed of GitLab.com even if we grow 10x over a few months.

There is already built-in support for pull request[1] and patch based workflows in Git itself. Why do we need to wait for, and choose based on, hosted services providing things like that? EDIT: for more clarity; using pull requests and patches with Git itself means that it simple to rebase or whatever, since you're just working with branches and patches directly.

Or am I missing something? Other than something like usability, perhaps...

[1] I'm not actually quite sure if there is a specific command for that format. Though it should be easy enough to have a third party solution that uses a format through email.

I hate that github does pull request merges with --no-ff, so what happens is that I manually pull the PR, merge it locally, and push. Github is nice enough to notice that the PR was merged, so its status is appropriately closed (if that was a fast forward, I don't think it detects rebases), but that makes me have to go out of the browser to start typing commands when I could have just clicked a button and be done with it. Essentially, it's a smoothness problem.

Only in the enterprise edition though.

No the efforts are for .com https://gitlab.com/gitlab-com/operations/issues/42

GitLab.com runs GitLab EE. So - if you compare features of github hosted and gitlab hosted, it's best to compare EE. (For example, GitLab.com hosts private repos, for free, and it's EE.)

Reply on news.ycombinator.com