> If I clone a repo, I want a pretty limited history for that repo when I clone. If I start to go back in time, spin up a worker to go fetch that stuff from the VCS when I need it.
> PR approval is too boolean. The PR is approved or it's not approved. Real code review, like real life, lives in the middle
This is have-your-cake-and-eat-it. PR approval is a permission so is a boolean. Of course it is. Either the code can be merged or it can't.
What's being described really here is just something to make you feel slightly better about yourself whilst approving code you hate ("we should revisit this..."). Just open a new ticket.
I was in camp 'boolean', but I think this has convinced me. I always had a problem that there were developers who didn't really understand the code, but would click 'approve' anyhow because they didn't see any problems in the parts they understood.
This meant that they were completely unable to actually 'approve' a review, but were only able to reject it. They were juniors, so they'd eventually get to that point, but by then, everyone would be used to just ignoring their approvals.
The nuance is comments on the PR itself, rather than the state of the approval, which is binary (or ternary, if you want to count leaving it in an unknown state for extended periods of time).
The PR needs to have someone who knows the whole thing.
Having several people review each separate parts but not understanding the others' can cause interaction bugs. If such bugs cannot happen (say, due to modularity, or type safety guarantees etc), then it won't be the case where you need to have a partial approve.
I am not a fan of partial approve. Either you think the code is approvable, or it isn't.
I mean, that’s fair no? If the UX creates an impasse for the user then this leads to friction in the process. There’s more than one way to address it. One is the user overcomes his own internal dilemma, the other is the UX helps him get there. For example, would be cool if there was a way to do a conditional approval with an issue tied to a stacked PR or something similar (just throwing ideas, point is to surface up the friction as a UX take not a protocol or API issue with git)
I would use RFC2822 as the underlying format to store any kind of message (pull request, review comment, issue etc.), and of course when displaying messages use CommonMark to style them. Any metadata goes into headers, and Message-ID/In-Reply-To/References headers can be used to link them all together. Using this well defined format you can then decide how to best store and transport all the messages, maybe in a git repo as well, use email, or whatever else works.
I personally think Gerrit works much better than whatever GitHub et al. have for code reviews. As for CI, I would try to keep that out of it as much as possible; just hooks to start a pipeline and to display the result and decide whether to allow a merge or not.
It does a mediocre job at all 4. But it does a good job of integrating them all together.
So I agree Gerrit is the superior code review model. but without the other 3 pieces you don't have a product. Even when I was at Google and working every day in Gerrit, I was dissatisfied with the poor integration between code search and code review and with CI.
Google3/Critique/Forge/etc -- Google's internal tooling -- did a much better job of tying that all together.
> This person has a family. This person has hobbies. This person is, at this moment, crying.
Reminded me one benefit of email-based workflow.
If I started receiving email, that's usually because I'm in the right mood to doing so. In such mood, I'll be more focused because I expect nothing else to interrupt my work.
My problem with notification is that there's a pull towards clearing them as they show up. But there's no guarantee I have the right energy at the moment.
Also, I found that most notification systems on the web are poor mimics of what email client has already archived decades ago. Maybe the old folks really got it right for using emails.
I think there's a gap in the market for a much simpler type of git service. All I need is a remote host to which I can push projects for others to see. I don't particularly want pull requests, actions or anything like that.
Maybe a way of facilitating "releases" with compiled binary assets (built locally and uploaded).
Forks can be handled by people cloning the repository and uploading a new project.
Can't a lot of this be accomplished by disabling features you don't need? I just checked my Forgejo instance and per repository there are options to disable: Code, Projects, Releases, Packages, Actions, Issues, PRs & Wikis.
If i was making my own GitHub, i would make it possible to put one deploy keys to multiple repos, same as in Gitea. Why that doesn't work is beyond me and is a major pita with no simple work arounds
If gitlab makes even some of its current premium features free (mostly around push rules, and merge dequest guardrails), most comoanies will host their own gitlab in a heartbeat.
> Let me do an enforced pre-commit hook to run the jobs remotely on the forge and provide the feedback to the user before they push.
You have to 'push' the code to the forge to run it. This code is a 'branch' of the version that is on repo.
> The PR is approved or it's not approved
The code is either merged or it's not. Sure you can trivially add a snooze feature...
> I don't need 4 eyes on every change, especially in a universe where LLMs exist.
Huh, I do. Anyone thinking LLMs replace human review, when LLMs are already replacing the coders, is just vibe-coding, not building a reliable library.
> Stacked PRs are just better.
I have no idea what this really means honestly. You can stack multiple commits in a single PR. You can create PRs based on other MRs.
> A forge shouldn't do everything. Issue tracking yes. Kanban board, probably not.
The board has to live in-sync with the issues or it's not a board.
If I were starting such a project -- and I must resist the temptation to do so -- I'd start by taking a very close look at Gerrit.
As a technology base to fork from, probably not ideal. But its flows are something to learn from.
The PR process in GitHub has always been garbage, and its cargo cult adoption by the whole industry is sad. But also unnecessary. There were always alternatives, but GH's refusal to do proper multi-round review and its tendency to encourages giant messy merge commits with no ability to track discussions between changes is an organizational nightmare, and now with LLMs it's even more terrifying.
Every company I've worked at since I left Google has had this problem with giant "take it or leave it" submissions. Dozens of commits in one "review". No ability to properly track changes between revisions. A mess of commits that all land at once.
I don't see how one can build a serious software team structure over top of this. It's a mess. And GitLab only makes it slightly better.
> If I clone a repo, I want a pretty limited history for that repo when I clone. If I start to go back in time, spin up a worker to go fetch that stuff from the VCS when I need it.
You want blobless clones:
Gets history and only fetches blobs on demand. Github has a great article on it https://github.blog/open-source/git/get-up-to-speed-with-par...> PR approval is too boolean. The PR is approved or it's not approved. Real code review, like real life, lives in the middle
This is have-your-cake-and-eat-it. PR approval is a permission so is a boolean. Of course it is. Either the code can be merged or it can't.
What's being described really here is just something to make you feel slightly better about yourself whilst approving code you hate ("we should revisit this..."). Just open a new ticket.
Gerrit has -2...+2.
-2: This is a bad idea, don't do that
-1: This is a good idea but needs improvement
+1: LGTM but I don't have enough knowledge or authority to approve
+2: Approved
I was in camp 'boolean', but I think this has convinced me. I always had a problem that there were developers who didn't really understand the code, but would click 'approve' anyhow because they didn't see any problems in the parts they understood.
This meant that they were completely unable to actually 'approve' a review, but were only able to reject it. They were juniors, so they'd eventually get to that point, but by then, everyone would be used to just ignoring their approvals.
This provides that middle ground.
Either the code gets merged or it does not. That's the inherent boolean part.
Given that, what's wrong with simply commenting on the PR to document the concerns, issues, lack of knowledge, etc?
Unless you're using those +/-2 to achieve some sort of goal... but you can also do that with labels, tags, etc. on the PR.
This seems like it’s conflating problems. It’s actually two different problems:
1. Is the PR suitable, and therefore should be approved, and
2. Is this person suitable to make that decision.
If 2 is false then the person should remove themselves from the list of reviewers. Then 1 can follow its normal process.
everything except +2 is unapprove.
The nuance is comments on the PR itself, rather than the state of the approval, which is binary (or ternary, if you want to count leaving it in an unknown state for extended periods of time).
What if you want someone to look at a portion of it but they don't know enough to approve the whole thing. They give +1
Someone else knows the other portion well and sees the +1 and decides to +2.
In practice this ends the stalemate where partial owners don't feel confident to approve the whole thing
The PR needs to have someone who knows the whole thing.
Having several people review each separate parts but not understanding the others' can cause interaction bugs. If such bugs cannot happen (say, due to modularity, or type safety guarantees etc), then it won't be the case where you need to have a partial approve.
I am not a fan of partial approve. Either you think the code is approvable, or it isn't.
And Gerrit has multiple review label that can be customized[0].
So you could require `Verified+2` (CI), `Code-Review+2`, and `Design+2`, for example.
[0]: <https://gerrit-review.googlesource.com/Documentation/config-...>
I mean, that’s fair no? If the UX creates an impasse for the user then this leads to friction in the process. There’s more than one way to address it. One is the user overcomes his own internal dilemma, the other is the UX helps him get there. For example, would be cool if there was a way to do a conditional approval with an issue tied to a stacked PR or something similar (just throwing ideas, point is to surface up the friction as a UX take not a protocol or API issue with git)
This exists in Azure DevOps as Approve with Suggestions
> There are a lot of tools that do parts of this. I want someone to take them, put them all together and fit them up.
But just a few inches earlier, the author stated:
> Everything tools always turn into crap.
This seems like a contradiction to me.
I would use RFC2822 as the underlying format to store any kind of message (pull request, review comment, issue etc.), and of course when displaying messages use CommonMark to style them. Any metadata goes into headers, and Message-ID/In-Reply-To/References headers can be used to link them all together. Using this well defined format you can then decide how to best store and transport all the messages, maybe in a git repo as well, use email, or whatever else works.
I personally think Gerrit works much better than whatever GitHub et al. have for code reviews. As for CI, I would try to keep that out of it as much as possible; just hooks to start a pipeline and to display the result and decide whether to allow a merge or not.
So I think part of the attraction with GitHub is the integration of all 4:
1. Code review 2. Source browsing 3. Ticket tracking 4. CI
It does a mediocre job at all 4. But it does a good job of integrating them all together.
So I agree Gerrit is the superior code review model. but without the other 3 pieces you don't have a product. Even when I was at Google and working every day in Gerrit, I was dissatisfied with the poor integration between code search and code review and with CI.
Google3/Critique/Forge/etc -- Google's internal tooling -- did a much better job of tying that all together.
> This person has a family. This person has hobbies. This person is, at this moment, crying.
Reminded me one benefit of email-based workflow.
If I started receiving email, that's usually because I'm in the right mood to doing so. In such mood, I'll be more focused because I expect nothing else to interrupt my work.
My problem with notification is that there's a pull towards clearing them as they show up. But there's no guarantee I have the right energy at the moment.
Also, I found that most notification systems on the web are poor mimics of what email client has already archived decades ago. Maybe the old folks really got it right for using emails.
A email is a notification,so how you are in the mood when it will come.can you elaborate clearly
Close the email client. No emails, no notifications.
In the mood for dealing with email, open client.
I think there's a gap in the market for a much simpler type of git service. All I need is a remote host to which I can push projects for others to see. I don't particularly want pull requests, actions or anything like that.
Maybe a way of facilitating "releases" with compiled binary assets (built locally and uploaded).
Forks can be handled by people cloning the repository and uploading a new project.
Can't a lot of this be accomplished by disabling features you don't need? I just checked my Forgejo instance and per repository there are options to disable: Code, Projects, Releases, Packages, Actions, Issues, PRs & Wikis.
Yes. But I would like a public service that took care of that for me. So like github but without the bells and whistles.
Part of the reason for not wanting bells and whistles is for the service to have less chance of dying under a heavy load.
Pretty much what sourcehut is. In addition you get a public mailing list where people can send issues and patch to.
Oh interesting! I've heard of sourcehut of course, but never looked at it. Thanks for the pointer.
If i was making my own GitHub, i would make it possible to put one deploy keys to multiple repos, same as in Gitea. Why that doesn't work is beyond me and is a major pita with no simple work arounds
I don’t understand why any of this would take submarine money to build. GitHub itself certainly wasn’t built with submarine money.
It doesn't need a lot of money, but it needs some absolutely gifted UX designers.
Working on it :P I’m going to take the idea to add a ‘defer’ button to PR comments. Which is fantastic.
If gitlab makes even some of its current premium features free (mostly around push rules, and merge dequest guardrails), most comoanies will host their own gitlab in a heartbeat.
As someone that hasn't touched Gitlab in a long time, what are some examples of their merge request guardrails?
Mostly agree with everything, but I will not stand for this slander against sweet potato fries!!!
I dream of a world of stagit + issue creation written in Rust. End
Why would issue creation written in rust be any better?
> Let me do an enforced pre-commit hook to run the jobs remotely on the forge and provide the feedback to the user before they push.
You have to 'push' the code to the forge to run it. This code is a 'branch' of the version that is on repo.
> The PR is approved or it's not approved
The code is either merged or it's not. Sure you can trivially add a snooze feature...
> I don't need 4 eyes on every change, especially in a universe where LLMs exist.
Huh, I do. Anyone thinking LLMs replace human review, when LLMs are already replacing the coders, is just vibe-coding, not building a reliable library.
> Stacked PRs are just better.
I have no idea what this really means honestly. You can stack multiple commits in a single PR. You can create PRs based on other MRs.
> A forge shouldn't do everything. Issue tracking yes. Kanban board, probably not.
The board has to live in-sync with the issues or it's not a board.
If I were starting such a project -- and I must resist the temptation to do so -- I'd start by taking a very close look at Gerrit.
As a technology base to fork from, probably not ideal. But its flows are something to learn from.
The PR process in GitHub has always been garbage, and its cargo cult adoption by the whole industry is sad. But also unnecessary. There were always alternatives, but GH's refusal to do proper multi-round review and its tendency to encourages giant messy merge commits with no ability to track discussions between changes is an organizational nightmare, and now with LLMs it's even more terrifying.
Every company I've worked at since I left Google has had this problem with giant "take it or leave it" submissions. Dozens of commits in one "review". No ability to properly track changes between revisions. A mess of commits that all land at once.
I don't see how one can build a serious software team structure over top of this. It's a mess. And GitLab only makes it slightly better.