> 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 was flawed and got rejected later.
There's a reason git and most accepted development workflows are linear.
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.
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.
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.
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.
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.
I appreciate you recognize there is still a reason for grouping commits into mergeable units (PRs). Some go too far and only want every commit to be independent.
I also appreciate the ordering. In my projects, we put an extra focus on tests by having having a commit that adds new tests to reproduce the bad behavior so when you diff the tests with the fix commit, you get a visual of how things changed.
I also find that the order can be PR specific. I wonder about allowing the contributor or reviewrs reorder on per-PR basis.
There are also times we have a lot of test or doc changes. I wonder about grouping items to jump between or collapsing to more easily navigate around than opening and browsing a file picker.
Jujutsu is interesting in that it appeals both to Git enthusiasts, and people who strongly dislike Git's UX. It's great to see it spurring more innovation in the ecosystem around it.
Though if it can just make stacked PRs widespread, I'd already be very happy.
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.
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 speed this up.
Lucky you. Blog.js fails for me with a TypeError and I'm disinclined to debug someone else's javascript on a whim, so I don't get to see any of the content at all.
To the OP: JS is for enhancements. If you are using it in such a way that it becomes a potential blocker for all of the content then you are not going to reach the audience that you otherwise would. If you are on somebody else's platform/framework then by all means pass this up the chain.
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.
The platform this is an ad for looks to be very bare-bones, but I’m still very glad to see a new entry in the code forge space focusing on stacked PRs since Graphite went all-in on clanker review. Extremely keen to see what will come out of ERSC [0]
I 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.
... 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.
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.
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 <maybe> an LLM could parse my garbage intermediate commits, the final diff and generate a stack instead?
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.
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™
> 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 was flawed and got rejected later.
There's a reason git and most accepted development workflows are linear.
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.
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.
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.
And thus, you don't have to build on every single unreviewed PR - but often it's quite sane to do so.
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.
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.
I appreciate you recognize there is still a reason for grouping commits into mergeable units (PRs). Some go too far and only want every commit to be independent.
I also appreciate the ordering. In my projects, we put an extra focus on tests by having having a commit that adds new tests to reproduce the bad behavior so when you diff the tests with the fix commit, you get a visual of how things changed.
I also find that the order can be PR specific. I wonder about allowing the contributor or reviewrs reorder on per-PR basis.
There are also times we have a lot of test or doc changes. I wonder about grouping items to jump between or collapsing to more easily navigate around than opening and browsing a file picker.
Jujutsu is interesting in that it appeals both to Git enthusiasts, and people who strongly dislike Git's UX. It's great to see it spurring more innovation in the ecosystem around it.
Though if it can just make stacked PRs widespread, I'd already be very happy.
I'd love to see an example PR on lubeno vs github. That might show the comparison a bit better.
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.
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 speed this up.
Lucky you. Blog.js fails for me with a TypeError and I'm disinclined to debug someone else's javascript on a whim, so I don't get to see any of the content at all.
To the OP: JS is for enhancements. If you are using it in such a way that it becomes a potential blocker for all of the content then you are not going to reach the audience that you otherwise would. If you are on somebody else's platform/framework then by all means pass this up the chain.
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.
Mobile is particularly bad
https://pagespeed.web.dev/analysis/https-lubeno-dev-blog-rei...
The platform this is an ad for looks to be very bare-bones, but I’m still very glad to see a new entry in the code forge space focusing on stacked PRs since Graphite went all-in on clanker review. Extremely keen to see what will come out of ERSC [0]
[0] https://ersc.io/
I wonder how may engineers contribute to their code base on a daily basis.
I 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`.
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.
This is just an ad.
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.
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.
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 <maybe> an LLM could parse my garbage intermediate commits, the final diff and generate a stack instead?
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™