3 ms·

I'm not the GP but I can echo the sentiment. :) One middle-to-major annoyance I still have with gitlab though, is that merge requests across forks aren't visib

I'm not the GP but I can echo the sentiment. :) One middle-to-major annoyance I still have with gitlab though, is that merge requests across forks aren't visible from any automation via the destination repo. That is, if a bot account has access to the prod repo to perform CI builds, and somebody opens a MR from a private fork, the bot can't see it. This has made us adjust our workflow for pretty much all prod repos to push branches to be reviewed under a review/* branch on the destination repo, which is cumbersome and requires additional permissions. GitHub makes all pull requests available as branches on the destination repo via the refs/pulls/* namespace, and that's been really useful. It'd be awesome if gitlab had this too!

jobvandervoort 10y ago
~~Ah this is a good improvement that we should definitely pick up on the short term. I've added it to [0] for now, but I'll look into this more later, I'm sure that we've thought / planned about this before.~~ [0]: https://gitlab.com/gitlab-org/gitlab-ce/issues/19049 https://gitlab.com/gitlab-org/gitlab-ce/issues/19049 edit 2: You can do as requested actually [1] [1]: https://docs.gitlab.com/ce/user/project/merge_requests.html#checkout-merge-requests-locally https://docs.gitlab.com/ce/user/project/merge_requests.html#... In addition, from GitLab 8.12, we even store the refs for each deployment, making it super easy to check out what is live now.