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

21–30 of 96 posts

Re: Reinventing the pull request

#21

Post by i_cannot_hack »

vermilingua wrote: post #14
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.

There's only a limited amount of context and decisions that can be effectively communicated informally without looking at the code. Sometimes it is required that people look at the actual suggested implementation, and when doing so they might spot fundamental issues that had not been found beforehand. The conventional format for doing such a review is a PR.

Re: Reinventing the pull request

#23

Post by taspeotis »

Shank wrote: post #2

On my first load of this page, it took 4.85 seconds to get meaningful content and the whole page took 8.09s. The vast majority of the delay seems to be from assets like the PNG images and the fonts, which don't seem to be on a CDN. I am located in Tokyo, Japan, with a 1Gbps symmetric connection, so while I am regionally quite distant from the site, I assume, I still think there are ample CDNs available that would spe…

Mobile is particularly bad

https://pagespeed.web.dev/analysis/https-lubeno-dev-blog-rei...

Re: Reinventing the pull request

#24

Post by bkolobara »

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…

You can just start a new branch in parallel if you don't need to build on top of the foundation. But if you are happy with the foundation and the next feature requires it, you can also continue working on something else. Jujutsu's automatic change propagation to children can also help if you need to adjust the foundation. For me work is mostly continues, like a flow.

Re: Reinventing the pull request

#26

Post by jmalicki »

IshKebab wrote: post #20

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…

You can manually stack PRs by making the merge target another branch.

The workflow just makes it a pain, since you have to manually rebase in both the branch and the UI after the original PR merges.

Re: Reinventing the pull request

#27

Post by bkolobara »

Shank wrote: post #2

On my first load of this page, it took 4.85 seconds to get meaningful content and the whole page took 8.09s. The vast majority of the delay seems to be from assets like the PNG images and the fonts, which don't seem to be on a CDN. I am located in Tokyo, Japan, with a 1Gbps symmetric connection, so while I am regionally quite distant from the site, I assume, I still think there are ample CDNs available that would spe…

Sorry about that! Performance is really important to me, I just didn't get around to configuring CDN caching and optimizing the assets. All the HN traffic hitting our server also didn't help.

Re: Reinventing the pull request

#28

Post by bkolobara »

lapcat wrote: post #5

This blog post is self-promotion, essentially an advertisement for a paid product, Lubeno, submitted by the developer of the product.

... on a website owned by the VC that invested in the developer.

I believe that the ideas in the blog post are novel enough and should spark curiosity and interesting discussions. Also I submitted this last week, someone must have hand-picked and given it another chance because it's a good fit for HN.

Re: Reinventing the pull request

#29

Post by IshKebab »

jmalicki wrote: post #26
IshKebab wrote: post #20

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…

You can manually stack PRs by making the merge target another branch. The workflow just makes it a pain, since you have to manually rebase in both the branch and the UI after the original PR merges.

That doesn't work if the base and PR branch are in different repos, which is the most common way of doing things in Github.

Re: Reinventing the pull request

#30

Post by vidarh »

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…

I do that a whole lot because most of the time I know the foundation will be accepted mostly as-is, maybe with small tweaks but not major changes.

So I branch of a previous PR instead of development when the changes are related, and continue development, and rebase after the previous PR has been merged.

Usually this leads to less rework and fewer merge conflicts.

Very occasionally it means having to rework subsequent work because the approach was actually wrong, but I'll take that over the hassle of continuing to work from a base I know is already outdated.

Post reply on HN