4 ms·

Gitlab's pull request functionality is inferior to both Github and Teams. We use them because their Kanban is nice and they're a bit more "one stop shop" than G

Gitlab's pull request functionality is inferior to both Github and Teams. We use them because their Kanban is nice and they're a bit more "one stop shop" than Github, but this pricing change doesn't make sense for us.

jrochkind1 4y ago
> We use them because their Kanban is nice Did you notice Github's improvements to "projects" over the past couple years? I feel like they missed doing a big announcement, cause it was like gradually implemented as a "beta" and then slowly filled in. But it's much better kanban now. Might still not be as good as gitlab's, I couldn't say.
mdaniel 4y ago
I don't work for GL but I'd be interested to hear what you think makes the GL pull request functionality inferior (my guess is you're going to say the number of "actions" available that target the GH API but it's just a guess)
- debacle 4y ago
  Large PRs are buggy, the flow is less intuitive, and in certain instances the PR UI just "breaks" and you need to refresh the page. Sometimes diffs are bad (I would bet github uses diff -ow, or something similar) and in general PRs are a drag.
  - mdaniel 4y ago
    Thank you. I've been following these family of bugs for what feels like years (although this specific one has _only_ been open 6 years): https://gitlab.com/gitlab-org/gitlab/-/issues/16448 https://gitlab.com/gitlab-org/gitlab/-/issues/16448 Typing out 85 review comments and having them swallowed by a 500 response because the frontend thought that of course XHRs are always 200 OK, why wouldn't they be? is indescribably infuriating
    - polskibus 4y ago
      try VSCode plugin for reviewing large MRs.
      - mdaniel 4y ago
        Thank you for your suggestion. I don't want to locally clone every project and then checkout every branch of MRs assigned to me just to work around their XHR issues If I had more energy, I'd try that on some big MR to just to find out whether their stupid extension also just assumes all XHRs are 200 OK. That'd be some icing on the cake
    - ZephyrBlu 4y ago
      What the hell. I'd be extremely pissed off if that happened to me. Does GitLab not save reviews as you go like GitHub seems to?
      - mdaniel 4y ago
        It "saves" them in that they are persisted on the server (as best I can tell) but the sequence is 1. POST /review/temp 1. POST /review/temp # all done, submit the batch 1. POST /review/submit <- 500 Oops we sorrwweee # now every comment is gone I don't recall this second whether the actual sequence is "POST" followed by "DELETE /review/temp" meaning this is 100% a JS bug or whether it's "POST" and the controller for submit nukes the temp version, making it a ruby bug And yes, "extremely pissed" isn't strong enough but ... put it on the list of the other 48,000 issues, I guess

jrochkind1 4y ago

> We use them because their Kanban is nice Did you notice Github's improvements to "projects" over the past couple years? I feel like they missed doing a big announcement, cause it was like gradually implemented as a "beta" and then slowly filled in. But it's much better kanban now. Might still not be as good as gitlab's, I couldn't say.

mdaniel 4y ago

I don't work for GL but I'd be interested to hear what you think makes the GL pull request functionality inferior (my guess is you're going to say the number of "actions" available that target the GH API but it's just a guess)

debacle 4y ago
Large PRs are buggy, the flow is less intuitive, and in certain instances the PR UI just "breaks" and you need to refresh the page. Sometimes diffs are bad (I would bet github uses diff -ow, or something similar) and in general PRs are a drag.
- mdaniel 4y ago
  Thank you. I've been following these family of bugs for what feels like years (although this specific one has _only_ been open 6 years): https://gitlab.com/gitlab-org/gitlab/-/issues/16448 https://gitlab.com/gitlab-org/gitlab/-/issues/16448 Typing out 85 review comments and having them swallowed by a 500 response because the frontend thought that of course XHRs are always 200 OK, why wouldn't they be? is indescribably infuriating
  - polskibus 4y ago
    try VSCode plugin for reviewing large MRs.
    - mdaniel 4y ago
      Thank you for your suggestion. I don't want to locally clone every project and then checkout every branch of MRs assigned to me just to work around their XHR issues If I had more energy, I'd try that on some big MR to just to find out whether their stupid extension also just assumes all XHRs are 200 OK. That'd be some icing on the cake
  - ZephyrBlu 4y ago
    What the hell. I'd be extremely pissed off if that happened to me. Does GitLab not save reviews as you go like GitHub seems to?
    - mdaniel 4y ago
      It "saves" them in that they are persisted on the server (as best I can tell) but the sequence is 1. POST /review/temp 1. POST /review/temp # all done, submit the batch 1. POST /review/submit <- 500 Oops we sorrwweee # now every comment is gone I don't recall this second whether the actual sequence is "POST" followed by "DELETE /review/temp" meaning this is 100% a JS bug or whether it's "POST" and the controller for submit nukes the temp version, making it a ruby bug And yes, "extremely pissed" isn't strong enough but ... put it on the list of the other 48,000 issues, I guess