social.noyu.me

github pull requests are a fucking nightmare, they need to abolish these yesterday and replace them with gerrit-style change reviews, the horrors never end, they never end, they never end, history becomes worthless, the review process is painfully disorganised, it must Die

@hikari What's your take on Git*Lab*'s Merge Requests workflow?

@hikari It does not have to be used that way, but here is my observed difference in how people use the two systems: GitHub's PRs are from clone repo to source repo, while GitLab's MRs are inside the same repo from a contributor's branch to a maintainer branch.

GitHub [simplified] steps are across repos:
1. Clone repo to contributor or update if cloned before
2. Push a patch to contributor's main.
3. Send a PR
4. Clean up once PR is decided

GitLab's [simplified] steps are in the same repo:
1. Check out (or use WebUI to make) a contributor's branch
2. Push a patch to the contributor's branch
3. Send an MR to the main (auto-sweep contributor's branch on merge)

An apparent downside in the latter workflow is that a maintainer needs to sweep abandoned contributor's branches.

However, I also saw that users perceive working on a branch as a process with less friction, at least in corporate environments. I did not observe much OSS development collaboration on GitLab.

@vldi @hikari my company uses GitHub PRs within the same repo in a similar way to your Gitlab example. I guess the only difference is when GitHub doesnt give contributors permission to make a branch, but really a fork is the same thing with a bit more annoyance

@hikari @vldi yeah, they’re pretty much the same. But even worse for dependent patches