[KwanEsq]

Huh, reading the penultimate "“Units of change” and collaboration" section reinforces the feeling that Github PRs really are a poor way to do code submission/review, and have been holding back a lot of the industry from better ways of working for a long time.

[andrewaylett]

GitHub-style PRs are the worst way of reviewing changes, except (in practice, if not in theory) for all the others :P.

When my then-employer first stated using git, I managed to convince them to set up Gerrit -- I had my own personal Gerrit instance running at home, it was great. I think it lasted about a year before the popularity factor kicked in and we switched to GitLab.

At least part of the difficulty is that approximately everyone who would need to learn how to use a new mechanism is already familiar with PRs. And folk new to the industry learn pretty quickly that it's normal and "easy". The cultural inertia is immense, and that means we're much more likely to evolve our way out of the hole (or switch to a completely different paradigm) than we are to en-mass switch to a different way of working that's still Git.

There are ways to make the PR experience more reasonable; GitHub has introduced stacked PRs which queue up. Even without that, I find disabling merge commits puts my team in a sweet spot where even if I'd prefer Gerrit, I'm not tearing my hair out and neither are the rest of my team who (mostly) don't care all that much.

[verall]

I get to use both Gerrit (rebase-cherrypick workflow) and gitlab (PR/MR workflow) at work.

I think that MR is better for smaller projects i.e. ~10devs - it's lower overhead, just commit while you work then write up a description when you push.

I think rebase-CP is better for larger projects like ~100 devs committing to a repo - linear git history and every commit having a clear description+purpose+review is worth the overhead at that point.

So one-off tools and infra and stuff get chucked into gitlab while "the product" is in Gerrit.

[hdjrudni]

I've never really used Github's PR system, always something else, but once in awhile I stumble in there in there from an opensource repo and they seem impossible to read with the individual commits.

Why doesn't Github just flatten/squash the stack of commits visually? Like I don't care what they're doing inside .git, can't they just diff the latest commit against the base commit and display that? So it's visually merged even if it's not merged in git's log?

---

At my work we do single commit. I find it annoying to work that way, I sometimes try to make clones of certain commits so I can restore to that point if I need to, but for reviewing, having everything in one neat little bundle, it's nice.

[ngrilly]

> GitHub has introduced stacked PRs which queue up

I missed that. How does it work?

[andrewaylett]

It's only available for orgs, not for personal repositories, and when we tried to use it in my team the size of our OIDC claim meant something broke so we had to turn it back off again :P. So I didn't get much experience with it.

But it seems like it gives you a place in a queue, meaning you don't need to keep rebasing as earlier PRs get merged: you can see what the state of the main branch should be by the time your PR reaches the head of the queue and develop accordingly.

https://docs.github.com/en/repositories/configuring-branches...

[ngrilly]

Thanks!

[doublerebel]

Graphite app helps with stacked PRs and has a good explanation. Not affiliated just a happy user

[dorian-graph]

It's maddening, considering their size, and that there are proven other examples out there of versioned change sets and divorcing the commit ID from the content ID.