Earlier quoted context omitted.
link?
https://github.com/github/roadmap/issues/1218 is the tracking issue for it
Locked... I'm like 40% sure they'll mess this up in some way that makes it completely useless.
Reinventing the pull request
71–80 of 96 posts
Re: Reinventing the pull request
#72Regarding PRs. I have a an opinion which has become very unpopular since the rise of github. The way github does PRs is great for open source projects where you have submissions from a very diverse set of developers. You need to evaluate the whole PR as whole and accept it or reject it. But it is not ideal where you have a small team working on single product. The PR review becomes a gate and it has been my experienc…
PRs can contain multiple commits. You need something like stgit to make it easy to make a bunch of small commits that appear to be the work of an omniscient genius who knew exactly what they were doing. Try using stgit for awhile, and you'll wonder how you ever lived without it.
Re: Reinventing the pull request
#73[dead]
Re: Reinventing the pull request
#74> So even when you have a nicely structured commit history, you end up realizing that some things need to be changed and start appending a bunch of "fix" and "actual fix" commits at the end.
I have found that this no longer needs to be an issue with agentic coding tools.
Once I am happy with the end state of a branch, I tell Claude to rebuild the change from scratch as a set of atomic incremental commits. It adds about 2 minutes to the dev process, but creates a pr that is infinitely easier to review.
The overall thrust of the article is great, though. The tooling around prs needs a ton of attention.
Re: Reinventing the pull request
#75> So even when you have a nicely structured commit history, you end up realizing that some things need to be changed and start appending a bunch of "fix" and "actual fix" commits at the end. I have found that this no longer needs to be an issue with agentic coding tools. Once I am happy with the end state of a branch, I tell Claude to rebuild the change from scratch as a set of atomic incremental commits. It adds abo…
[deleted]
Re: Reinventing the pull request
#76Are devs really reviewing AI generated code? It just seems so pointless. Nobody was reviewing protoc generated code, for example, and most of my colleagues (not faang, but one level below) simply comment “LGTM!” or equivalents when a PR smells like ai generated code. Seems fair.
Even more so if I add a comment to a PR and what I get in reply is an AI generated reply with AI generated commit (you can tell also because of the “Coauthor Claude” thingy in the commit)
Re: Reinventing the pull request
#77> Once you have the power to do a bunch of small self-contained changes, you want PRs to consist of one or two commits. You want to build on previous changes without needing to wait for them to be reviewed. Lubeno helps you to do exactly this. Why would I want to build on changes that haven't been reviewed and accepted? That's a good way to waste my time having to redo something because the foundation it was based on…
> Why would I want to build on changes that haven't been reviewed and accepted?
Not to waste time not being able to do anything that depends on those changes?
> git and most accepted development workflows are linear.
Linear like branches easily branching off other branches?
Re: Reinventing the pull request
#78Are devs really reviewing AI generated code? It just seems so pointless. Nobody was reviewing protoc generated code, for example, and most of my colleagues (not faang, but one level below) simply comment “LGTM!” or equivalents when a PR smells like ai generated code. Seems fair. Even more so if I add a comment to a PR and what I get in reply is an AI generated reply with AI generated commit (you can tell also because…
> Nobody was reviewing protoc generated code
Are you seriously comparing LLMs with a deterministic code generator?
Re: Reinventing the pull request
#79I apreciate the fact that they mention that sometimes a commit change needs a fix before it ever even was pull-request ready. I think it would be great to have the ability to easily reorder/modify commits while in active development, and then lock them into permanent history afterwards. Apparently (according to the article) Jujutsu can do that, but I've never had personal exoerience with that VCS.
> I think it would be great to have the ability to easily reorder/modify commits while in active development Take a look at `git rebase --interactive`.
That's not "easily". Easily would be: you drag your commit(s) from one place to another or copy/paste to achieve the same
Re: Reinventing the pull request
#80Are devs really reviewing AI generated code? It just seems so pointless. Nobody was reviewing protoc generated code, for example, and most of my colleagues (not faang, but one level below) simply comment “LGTM!” or equivalents when a PR smells like ai generated code. Seems fair. Even more so if I add a comment to a PR and what I get in reply is an AI generated reply with AI generated commit (you can tell also because…
> Are devs really reviewing AI generated code?
Definitely. Even the current leading edge AI models (ie Claude Code Opus 4.6 (1M)) gets things (badly) wrong occasionally, makes bad decisions, and does stupid stuff.
It's a lot better than even just a few months ago, but blinding accepting its output for code that matters will catch you out.