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

GitHub Stacked PRs

github.github.com

Post reply on HN
Print view View original

321–330 of 548 posts

Re: GitHub Stacked PRs

#321

Post by riffraff »

eqvinox wrote: post #130
smallmancontrov wrote: post #70

Earlier quoted context omitted.

I'm so glad git won the dvcs war. There was a solid decade where mercurial kept promoting itself as "faster than git*†‡" and every time I tried it wound up being dog slow (always) or broken (some of the time). Git is fugly but it's fast, reliable, and fugly, and I can work with that.

I remember using darcs, but the repos I was using it with were so small as to performance really not mattering…

I remember darcs fondly but even with tiny repos (maybe 5-6 people working on it) we hit the "exponential merge" issues.

It worked just fine 99% of the time and then 1% it became completely unusable.

Re: GitHub Stacked PRs

#322

Post by landr0id »

w0m wrote: post #302
landr0id wrote: post #266

Earlier quoted context omitted.

>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. Fun story: I don't really know what Microsoft's server-side infra looked like when they migrated the OS repo to git (which, contrary to the name, contains more than just stuff related to the Windows OS), but after a few years the…

didn't msft write an ~entire new file system specifically to scale git to the windows code base? I have fuzzy memories on reading about it.

They wrote something that allowed them to virtualize Git -- can't remember the name of that. But it basically hydrated files on-demand when accessed in the filesystem.

The problem was I think something to do with like the number of git objects that it was scaling to causing crazy server load or something. I don't remember the technical details, but definitely something involving the scale of git objects.

Re: GitHub Stacked PRs

#323

Post by fphilipe »

locknitpicker wrote: post #312
fphilipe wrote: post #309

I've been doing stacked PRs for ~2 years now. Thus, I don't quite see the need for this CLI. Git has had some additions in the last few years that make this work natively – specifically the --update-refs flag[1] or the rebase.updateRefs config. Combined with `git commit --fixup`, rebase.autoStash, and rebase.autoSquash rebasing stacks becomes a breeze (as long as you work off from the tip of your stack). Add in git-a…

> Git has had some additions in the last few years that make this work natively – specifically the --update-refs flag[1] or the rebase.updateRefs config. Combined with `git commit --fixup`, rebase.autoStash, and rebase.autoSquash rebasing stacks becomes a breeze (as long as you work off from the tip of your stack). Add in git-absorb[2] and the heavy-lifting is taken care of. ...or you don't bother with all that and s…

Sure, that's possible. I can also use the GitHub app and use a Git abstraction where I don't have to understand Git at all.

The point is that I want to use Git, a tool and skill that is portable to other platforms.

Re: GitHub Stacked PRs

#324

Post by steveklabnik »

dijit wrote: post #319
steveklabnik wrote: post #118

Earlier 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.

Yes, the server is based on Perforce, called Piper, but the CLI is based on mercurial. So locally you're doing hg and then when you create a CL, it translates it into what p4 needs.

Re: GitHub Stacked PRs

#325

Post by eru »

dtech wrote: post #293
jmalicki wrote: post #289

Earlier quoted context omitted.

Fair! I guess I didn't mean language as such, but as used. But a lot of the monkey-patching kind of things and dynamism of python also means a lot of those sorts of things have to be re-checked often for correctness, so it does take a ton of optimizations off the table. (Of course, those are rare corner cases, so compilers like pypy have been able to optimize for the "happy case" and have a slow fall-back path - but…

Javascript has a lot of the same theoretical dynamism, yet V8 and WebkitCore were able to make it fast

Yes, with heroic effort. It's really a triumph of compiler / vm engineers over language designers.

Re: GitHub Stacked PRs

#326

Post by eru »

dbetteridge wrote: post #299
eru wrote: post #288

Earlier quoted context omitted.

The point of what? I hope they fixed phabricator in the meantime.

The point is the main branch reflects the "units" of change, not the individual commits to get there. One merged pr is a unit of change, at the end of the day the steps you took to produce it aren't relevant to others. My opinion of course, I'm open to understanding why preserving individual commits is beneficial

You can get what you want from `git log --first-parent` without having to toss out information.

See how the Linux kernel handles git history to see a good example of non-linear history and where it helps. They use merge commits, ie commits with more than one ancestor, all the time.

Re: GitHub Stacked PRs

#327

Post by roca »

kqr wrote: post #307
landr0id wrote: post #266

Earlier quoted context omitted.

>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. Fun story: I don't really know what Microsoft's server-side infra looked like when they migrated the OS repo to git (which, contrary to the name, contains more than just stuff related to the Windows OS), but after a few years the…

I have heard that the Google monorepo is called google3 but I don't know why. Maybe those things are common...

It's not that.

Re: GitHub Stacked PRs

#328

Post by rs545837 »

This is awesome honestly, Stacked PRs are one of those features that feels obvious in hindsight. Breaking a n-line PR into 3 focused layers where each one is independently reviewable is a huge win for both the author and reviewer. The native GitHub UI with the stack navigator is the right call too, and there's no reason this should require a third-party tool.

One thing I keep thinking about in this same direction: even within a single layer of a stack, line-level diffs are still noisy. You rename a function and update x call sites, the diff shows y changed lines. A reviewer has to mentally reconstruct "oh this is just a rename" from raw red/green text.

Semantic diffing (showing which functions, classes, methods were added/modified/deleted/moved) would pair really well with stacks. Each layer of the stack becomes even easier to review when the diff tells you "modified function X, added function Y" instead of just showing changed lines.

I've been researching something in this direction, https://ataraxy-labs.github.io/sem/. It does entity-level diffs, blame, and impact analysis. Would love to see forges like GitHub move in this direction natively. Stacked PRs solve the too much at once problem. Semantic diffs solve the "what actually changed" problem. Together they'd make code review dramatically better.

Re: GitHub Stacked PRs

#329

Post by locknitpicker »

fphilipe wrote: post #323
locknitpicker wrote: post #312

Earlier quoted context omitted.

> Git has had some additions in the last few years that make this work natively – specifically the --update-refs flag[1] or the rebase.updateRefs config. Combined with `git commit --fixup`, rebase.autoStash, and rebase.autoSquash rebasing stacks becomes a breeze (as long as you work off from the tip of your stack). Add in git-absorb[2] and the heavy-lifting is taken care of. ...or you don't bother with all that and s…

Sure, that's possible. I can also use the GitHub app and use a Git abstraction where I don't have to understand Git at all. The point is that I want to use Git, a tool and skill that is portable to other platforms.

> The point is that I want to use Git, a tool and skill that is portable to other platforms.

You want to use git.

Most people around you want to get things done.

Re: GitHub Stacked PRs

#330

Post by riffraff »

dathanb82 wrote: post #226
nine_k wrote: post #95

Earlier quoted context omitted.

Can these tools e.g. do per-commit review? I mean, it's not the UI what's the problem (though it's not ideal), it's the whole idea of commenting the entire PR at once, partly ignoring the fact that the code in it changes with more commits pushed. Phabricator and even Gerrit are significantly nicer.

Unless you have a “every commit must build” rule, why would you review commits independently? The entire PR is the change set - what’s problematic about reviewing it as such?

There's a certain set of changes which are just easier to review as stacked independent commits.

Like, you can do a change that introduced a new API and one that updates all usages.

It's just easier to review those independently.

Or, you may have workflows where you have different versions of schemas and you always keep the old ones. Then you can do two commits (copy X to X+1; update X+1) where the change is obvious, rather than seeing a single diff which is just a huge new file.

I'm sure there's more cases. It's not super common but it is convenient.

Post reply on HN