This is useful. Managing dependencies across PRs has always been tricky — nice to see better workflows evolving.
GitHub Stacked PRs
391–400 of 548 posts
Re: GitHub Stacked PRs
#392Earlier quoted context omitted.
Now that is interesting too, because git is very fast for all I have ever done. It may not scale to Google monorepo size, it would ve the wrong tool for that. But if you are talking Linux kernel source scale, it asolutely, is fast enough even for that. For everything I've ever done, git was practically instant (except network IO of course). It's one of the fastest and most reliable tools I know. If it isn't fast for…
The fact that Git has an extremely strong preference for storing full and complete history on every machine is a major annoyance! “Except for network IO” is not a valid excuse imho. Cloning the Linux kernel should take only a few seconds. It does not. This is slow and bad. The mere fact that Git is unable to handle large binary files makes it an unusable tool for literally every project I have ever worked on in my en…
git clone --bare --depth=1 https://github.com/torvalds/linux
Takes 21 seconds on my work laptop, indeed a corporate Windows laptop with antivirus installed. Majority of that time is simply network I/O. The cloned repository is 276 MB large.
Actually checking the kernel out takes 90 seconds. This amounts to creating 99195 individual files, totaling 2 GB of data. Expect this to be ~10 times faster on a Linux file system.
So what's your problem?
Re: GitHub Stacked PRs
#393Interesting direction. Curious how this compares with traditional transformer-based approaches in real use cases.
Re: GitHub Stacked PRs
#394Earlier quoted context omitted.
What is kind of funny here is that you're right locally. At the same time, the larger tech companies (Meta and Google, specifically) ended up building off of hg and not git because (at the time, especially) git cannot scale up to their use cases. So while the git CLI was super fast, and the hg CLI was slow, "performance" means more than just CLI speed. I was never a fan of hg either, but now I can use jj, and get som…
Small nit: Googles monorepo is based on Perforce. I think what happened is Google bought a license for source code and customised it.
> Google bought a license for source code and customised it.
That makes sense because vanilla Perforce is unbearably slow and impossible to scale.
Last I checked, it was bought by Private Equity firms and actual product development had more or less stopped.
Re: GitHub Stacked PRs
#395This just reeks to me of bad practice. Why use this as opposed to breaking your change into smaller PRs and merging them individually behind a feature flag or similar? With this, you have a marginally better UX for reviewing through the Github website, but the underlying issues are the same. The change being introduced is not sufficiently testable by itself, or it's (somehow) too tightly coupled to other parts of the…
When I've reached for stacked PRs (in the past, not using this feature) it's precisely because I've split my change into smaller PRs being merged individually. I've just written those smaller PRs at once, or in quick enough succession that the previous PRs weren't merged before the later ones were ready. And the later ones relied on the previous ones because that's how working on a feature works. The earlier PRs are…
This is a perfect example that I've often seen in practice. There's nothing blocking in this workflow at all, and no reason these changes cannot be made in independent changes. e.g.
1) API implementation - Including tests and docs this should be perfectly acceptable to merge and review independently 2) UX implementation - Feature flagged, dummy API responses, easy to merge + review 3) One quick "glue" PR where the feature can be integration tested etc
This prevents awful merge conflicts, multiple rounds of increasingly complex stacked reviews, and a host of other annoyances.
Is there any reason that the stacked PR workflow is better that I'm ignoring or overlooking?
Re: GitHub Stacked PRs
#396I already do this using git branched. Whenever I have features that depends on one another I create a feature branch and then stack branches on top of each other for individual feature so it's easy for the reviewer to go through the code and and also keep the PR size quite small. Also this gives me freedom to push more than one commit for each branch to fix things.
The only annoying part is that I have to keep on merging the base branch to the feature branch constantly to keep it up-to date. If Github can provide a feature to do that automatically, then that would be perfect. Other than that, I don't see any advantage on this stacked PR approach they are proposing.
Re: GitHub Stacked PRs
#397I might be missing something, but what I need is not "stacked PR" but a proper UI and interface to manage single commit: - merge some commits independently when partial work is ready. - mark some commit as reviewed. - UI to do interactive rebase and and squash and edit individual commits. (I can do that well from the command line, but not when using the GitHub interface, and somehow not everyone from my team is famil…
You want something like Gerrit.
Re: GitHub Stacked PRs
#398Earlier quoted context omitted.
Right, and I'm glad there are projects serving The Cathedral, but I live in The Bazaar so I'm glad The Bazaar won. The efforts to sell priest robes to fruit vendors were a little silly, but I'm glad they didn't catch on because if they had caught on they no longer would have been silly.
GNU Bazaar thoroughly lost, last release was 2016, Canonical retired it last year: https://en.wikipedia.org/wiki/GNU_Bazaar
GP is taking about this[0] but it's quite hilarious that a VCS exists with that name.
0: https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar
Re: GitHub Stacked PRs
#399> Large pull requests are hard to review, slow to merge, and prone to conflicts. Reviewers lose context, feedback quality drops, and the whole team slows down. OK, yeah, I’m with you. > Stacked PRs solve this by breaking big changes into a chain of small, focused pull requests that build on each other — each one independently reviewable. I don’t get this part. It seems like you are just wasting your own time building…
This _is_ a solution to slow reviews. Smaller reviews are faster to get in. And many small reviews take less time to review than one large review. Plus there's no review that's instant. Being able to continue working is always better.
I am not arguing against small PRs.
Stacking PRs are not a way to make changes smaller and therefore not making reviews easier.
Re: GitHub Stacked PRs
#400Earlier quoted context omitted.
Whatever your opinion on one tool or another might be - it does seem weird that the "market" has been captured by what you are saying is a lesser product. IOW, what do you know that nobody else does?
So far you've only gotten responses to "how can a worse product win?", and they are valid, but honestly the problem here is that Mercurial is not a better product in at least one very important way: branches. You can visit any resource about git and branches will have a prominent role. Git is very good at branches. Mercurial fans will counter by explaining one of the several different branching options it has availab…
It's interesting that branches, which is a marquee feature of git, became less important at the same time as git ate all the other vcs. Outside of OS projects, almost all development is trunk based with continuous releases.
Maybe branching was an important reason to adopt git but now we'd probably be ok with a vcs that doesn't even support them.