3 ms·

if locked code review is coming in, i'll be all over it. just let me select multiple approvals, and nested approvals. it's an immensely useful feature. once ag

by ech 10y ago

if locked code review is coming in, i'll be all over it. just let me select multiple approvals, and nested approvals. it's an immensely useful feature. once again, the more i can define a process in software, the better it is for most non-western, non-modern-management companies.

sytse 10y ago
Are you familiar with the merge request approvers feature in EE https://about.gitlab.com/2015/06/16/feature-highlight-approve-merge-request/ https://about.gitlab.com/2015/06/16/feature-highlight-approv... ?
- superuser2 10y ago
  This is nice, but does not solve the problem of giving a user the power to approve merge requests but not accidentally "git push origin master."
  - sytse 10y ago
    With protected branches you can prevent force pushes to master. You would have to do a manual merge and then git push origin master to cause a problem I think.
    - superuser2 10y ago
      I don't generally use feature branches on solo projects. Working directly on master (and pushing origin master at arbitrary moments to back up my work) is a deeply ingrained habit. A code review tool that's off by default and trivial to bypass in your sleep is a poor code review tool. This is easy to prevent in Phabricator, which will block pushes to master if they contain changes not also present in an approved unit of code review. I run into that wall a few times a week, and am reminded to move my commits into a branch.
      - sytse 10y ago
        Thanks, good point. We're extending protected branches so all code will have to undergo a code review, see https://gitlab.com/gitlab-org/gitlab-ce/issues/18193 https://gitlab.com/gitlab-org/gitlab-ce/issues/18193
- ech 10y ago
  i am, i get people to use it, and it works well. but superuser2 is right. to be honest, i think we're touching to fundamental limitations in the git model that gitlab cannot solve without becoming rational team concert, and catering to a fundamentally different public.

by ech 10y ago

sytse 10y ago

Are you familiar with the merge request approvers feature in EE https://about.gitlab.com/2015/06/16/feature-highlight-approve-merge-request/ https://about.gitlab.com/2015/06/16/feature-highlight-approv... ?

superuser2 10y ago
This is nice, but does not solve the problem of giving a user the power to approve merge requests but not accidentally "git push origin master."
- sytse 10y ago
  With protected branches you can prevent force pushes to master. You would have to do a manual merge and then git push origin master to cause a problem I think.
  - superuser2 10y ago
    I don't generally use feature branches on solo projects. Working directly on master (and pushing origin master at arbitrary moments to back up my work) is a deeply ingrained habit. A code review tool that's off by default and trivial to bypass in your sleep is a poor code review tool. This is easy to prevent in Phabricator, which will block pushes to master if they contain changes not also present in an approved unit of code review. I run into that wall a few times a week, and am reminded to move my commits into a branch.
    - sytse 10y ago
      Thanks, good point. We're extending protected branches so all code will have to undergo a code review, see https://gitlab.com/gitlab-org/gitlab-ce/issues/18193 https://gitlab.com/gitlab-org/gitlab-ce/issues/18193
ech 10y ago
i am, i get people to use it, and it works well. but superuser2 is right. to be honest, i think we're touching to fundamental limitations in the git model that gitlab cannot solve without becoming rational team concert, and catering to a fundamentally different public.