Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reinventing the pull request

lubeno.dev

Post reply on HN
Print view View original

11–20 of 96 posts

Re: Reinventing the pull request

#11

Post by Vinnl »

petcat wrote: post #4

> 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…

Often it's very likely that previous ones won't need to change significantly, in which case disposing of having the full context while waiting for that review ends up slowing you down a lot. In those cases, often the main cause of extra busywork is Git administration, having to manually rebase sub-branches, and then losing in-progress reviews on those PRs as well.

Re: Reinventing the pull request

#12

Post by sbszllr »

Let's forget that this post is an ad. I feel like there is a use for LLMs that could help us do stacked PRs better.

Right now there are effectively three ways to do a PR:

- a bunch of small commits, some of them related to the feature, some fixes, some mixing both -> a PR with 'n' commits -> they don't really make sense as atomic commits, you have to review the entire PR to make the sense of it

- a squashed PR

- some uber principled reorganisation of commits that separates key implementation concerns into smaller commits (effectively stacked PRs but clean)

The last option would be desirable but it's unreasonable to expect anyone to do it by hand. So this is where an LLM could parse my garbage intermediate commits, the final diff and generate a stack instead?

Re: Reinventing the pull request

#13

Post by vermilingua »

sbszllr wrote: post #12

Let's forget that this post is an ad. I feel like there is a use for LLMs that could help us do stacked PRs better. Right now there are effectively three ways to do a PR: - a bunch of small commits, some of them related to the feature, some fixes, some mixing both -> a PR with 'n' commits -> they don't really make sense as atomic commits, you have to review the entire PR to make the sense of it - a squashed PR - some…

The last option is absolutely not unreasonable to expect people to do by hand, as the article states it’s simply a problem of tooling. JJ makes this extremely easy to do, but some of us have been doing just the same in git for a long time and it is extremely achievable once you know your way around a rebase.

Re: Reinventing the pull request

#14

Post by vermilingua »

petcat wrote: post #4

> 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…

If you’re getting to the point where you’re submitting PRs if you don’t know whether the foundation of the change is flawed, you have more pressing issues than wasting time in code review fixes.

Re: Reinventing the pull request

#16

Post by sbszllr »

vermilingua wrote: post #13
sbszllr wrote: post #12

Let's forget that this post is an ad. I feel like there is a use for LLMs that could help us do stacked PRs better. Right now there are effectively three ways to do a PR: - a bunch of small commits, some of them related to the feature, some fixes, some mixing both -> a PR with 'n' commits -> they don't really make sense as atomic commits, you have to review the entire PR to make the sense of it - a squashed PR - some…

The last option is absolutely not unreasonable to expect people to do by hand, as the article states it’s simply a problem of tooling. JJ makes this extremely easy to do, but some of us have been doing just the same in git for a long time and it is extremely achievable once you know your way around a rebase.

Maybe it just shows my lack of tolerance for process/overhead.

As a fellow rebase enjoyer, I will do it occasionally for smaller PRs but to me, it becomes unwieldy for large ones.

Do you have any tips or aliases that makes it more workable?

Re: Reinventing the pull request

#17

Post by catlifeonmars »

petcat wrote: post #4

> 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…

Anecdata, but I don’t find myself making major changes to code during review often. That speaks to a deeper problem (miscommunication of requirements, author skill, overly pedantic reviewers, etc).

Also, I don’t have time to wait around for a review to work on other parts of the same codebase.

Re: Reinventing the pull request

#18

Post by tfrancisl »

I work in between two teams that would prefer no code review except for by pair programming (militantly arguing that this is the only true trunk based development, those small PRs are something else) and a team that every individual wants to own the dev cycle end to end. So its either pushes to main youre forced to catch up on that you had no alerts or knowledge of, or +6000 -500 diff PRs with way too many features and no story to tell in the commits.

Maybe this tool would help, but nothing in this pitch convinces me.

Re: Reinventing the pull request

#19

Post by vermilingua »

sbszllr wrote: post #16
vermilingua wrote: post #13

Earlier quoted context omitted.

The last option is absolutely not unreasonable to expect people to do by hand, as the article states it’s simply a problem of tooling. JJ makes this extremely easy to do, but some of us have been doing just the same in git for a long time and it is extremely achievable once you know your way around a rebase.

Maybe it just shows my lack of tolerance for process/overhead. As a fellow rebase enjoyer, I will do it occasionally for smaller PRs but to me, it becomes unwieldy for large ones. Do you have any tips or aliases that makes it more workable?

Yep, ensuring RERERE and autostash are enabled eliminate 80% of the tedium for me, but honestly just try jj; it seriously is a gamechanger and (so far, in ~6mth of use) it has had literally zero drawbacks in comparison to git, because it is still git and if I don’t know how to do something with jj, I can use the git commands I do know and it Just Works™

Re: Reinventing the pull request

#20

Post by IshKebab »

It blows my mind that Github still doesn't support stacked PRs. Do they never do work that depends on an open PR? Like, as soon as they open a PR they're like "right, better stop doing anything until it's merged"?

The file priority thing is a great idea too. That would be even more useful for search. The number of times I'm searching for something on Github and it just shows me a gazillion tests.... Yeah you can look up their advanced search syntax and exclude them probably, but it's always a hassle.

Post reply on HN