4 ms·

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 me

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.

levlaz 11y ago
Very true, I think they are working very hard on improving the experience this quarter. Front page of HN probably does not help either. :)
- sytse 11y ago
  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.
enimodas 11y ago
Only in the enterprise edition though.
- levlaz 11y ago
  No the efforts are for .com https://gitlab.com/gitlab-com/operations/issues/42 https://gitlab.com/gitlab-com/operations/issues/42
- nearlythere 11y ago
  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.)
nearlythere 11y ago
Just wanted to point out the disadvantage statement came from https://about.gitlab.com/gitlab-com/ https://about.gitlab.com/gitlab-com/ At GitLab we are honest about issues, and transparent about what we're working on. HTH!
- levlaz 11y ago
  Thank you for your transparency, it means a lot! :)
throwaway999888 11y ago
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.
- deleted 11y ago
  [deleted]
- glandium 11y ago
  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.
jacobsenscott 11y ago
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.

levlaz 11y ago

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

sytse 11y ago
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.

enimodas 11y ago

Only in the enterprise edition though.

levlaz 11y ago
No the efforts are for .com https://gitlab.com/gitlab-com/operations/issues/42 https://gitlab.com/gitlab-com/operations/issues/42
nearlythere 11y ago
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.)

nearlythere 11y ago

Just wanted to point out the disadvantage statement came from https://about.gitlab.com/gitlab-com/ https://about.gitlab.com/gitlab-com/ At GitLab we are honest about issues, and transparent about what we're working on. HTH!

levlaz 11y ago
Thank you for your transparency, it means a lot! :)

throwaway999888 11y ago

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.

deleted 11y ago
[deleted]
glandium 11y ago
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.

jacobsenscott 11y ago

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.