Hacker News Reader

Comment by ech | Hacker News Reader

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.

View on HN

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

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."

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.

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.

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

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.

Reply on news.ycombinator.com