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

521–530 of 548 posts

Re: GitHub Stacked PRs

#521

Post by jstimpfle »

inejge wrote: post #359
surajrmal wrote: post #335

Earlier quoted context omitted.

You must belong to the club of folks who use hashmaps to store 100 objects. It's amazing how much we've brainwashed folks to focus on algorithms and lose sight of how to actually properly optimize code. Being aware of how your code interacts with cache is incredibly important. There are many cases of using slower algorithms to do work faster purely because it's more hardware friendly. The reason that some more modern…

> You must belong to the club of folks who use hashmaps to store 100 objects. Apparently I belong to the same club -- when I'm writing AWK scripts. (Arrays are hashmaps in a trenchcoat there.) Using hashmaps is not necessarily an indictment you apparently think it is, if the access pattern fits the problem and other constraints are not in play. > It's amazing how much we've brainwashed folks to focus on algorithms an…

Most code most people work on isn't about algorithms at all. The most straightforward algorithm will do. Maybe put some clever data structure somewhere in the core.But for the vast majority of code, there isn't any clear algorithmic improvement, and even if there was, it wouldn't make a difference for the typically small workloads that most pieces of code are processing.

I'll take it back a little bit, because there _is_ in fact a lot of algorithmically inefficient code out there, which slows down everything a lot. But after getting the most obvious algorithmic problems out of the way -- even a log-n algorithm isn't much of an improvement to a linear scan, if n < 1000. It's much more important to get that 100+x speedup by implementing the algorithm in a straightforward and cache friendly way.

Re: GitHub Stacked PRs

#522

Post by awesome_dude »

qsera wrote: post #465
jorams wrote: post #348

Earlier quoted context omitted.

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…

To me mercurials branching is closer to the development process and preserves more information, because it records the original branch a commit was made. Git does not have such concept. That is a trade off and that trade off works great for projects managed like Linux kernel. But for smaller projects where there is a limited number of people working, the information preserved by mercurial could be very valuable. It a…

Just FTR - git /can/ store that information, but it requires human input.

If you rebase the feature branch into the main branch THEN follow it up with the merge commit that records the branch name you store the branches (that have been made a part of main) and can see where they are in your log

Mercurial's notes can become cumbersome if there are a large number in the repository, but, obviously, humans can sort that out if it gets out of hand

Re: GitHub Stacked PRs

#523

Post by awesome_dude »

xmcqdpt2 wrote: post #400
jorams wrote: post #348

Earlier quoted context omitted.

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.

Trunk based development is still a hotly debated topic. I personally prefer branches at this point in time, trunk based development has caused me more trouble than it's claimed worth in the past, BUT that could be a me limitation rather than a limitation of the style

Re: GitHub Stacked PRs

#524

Post by awesome_dude »

krick wrote: post #416
xmcqdpt2 wrote: post #400

Earlier quoted context omitted.

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.

Not sure if it's true. I mean, I do agree with the core of it, but how do you even do PRs and resolve conflicts, if there are no branches and a developer cannot efficiently update his code against the last (remote) version of master branch?

Trunk based development has every developer in the company committing straight to main - no PRs, supposedly no merge conflicts (but reality is that main moves fast and if someone else is working in the same files as someone else, there will be merge conflicts)

A middle ground is small PRs where people are constantly rebasing to the tip of main to keep conflicts to a minimum

Re: GitHub Stacked PRs

#525

Post by AJRF »

poszlem wrote: post #387
AJRF wrote: post #366

I have never got a good answer to "can't you just make smaller PRs". This is convoluted tooling (needs its own CLI) for something you could achieve with just learning how git works.

Right, so 'just work the way the tool requires instead of making the tool work the way you want'. I would prefer the tool worked the way I want and the way I think of the changes instead.

I still don't have a single answer in this thread as to how even using this new tool even helps do things I can easily do with git?

> "Sometimes you just need to land changes all together".

Smell. What is that won't land? A UI change needed to go with a Database migration? That just tells me you don't flag your changes which you _should_ be doing. If you have code in your hot path that can break because of a DB or API change and you _don't_ flag that you have made your releases much more dangerous. Fix that before installing a new cli tool

If you can't do a database migration, you have put non optional new fields in somewhere, which doesn't accurately model your data domain - because it didn't exist before, it is tautologically optional.

> "How do I update a bunch of small PRs"

Smell. You should be merging small, flagged commits to main and rebase other branches. The workflow described is the same as feature branches - you start a branch, then branch from that, then branch from that - you shouldn't do that. That is not a git problem in the same way throwing every file on your desktop isn't an OS problem - you are just making a mess.

Re: GitHub Stacked PRs

#526

Post by kritr »

landr0id wrote: post #322
w0m wrote: post #302

Earlier quoted context omitted.

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.

Unfortunately even with these improvements, working in the repo was quite slow.

Changes branches took an eternity, and people resorted to a more workspaces style solution.

If you’re planning on starting a big tech company, I wouldn’t recommend the approach.

Re: GitHub Stacked PRs

#527

Post by herpdyderp »

sameenkarim wrote: post #514
herpdyderp wrote: post #439

Earlier quoted context omitted.

> so the diff in a PR shows just the relevant changes from the specific branch That's exactly right. > you can create stacked PRs purely via the UI How? I see from the docs https://github.github.com/gh-stack/introduction/overview : > When a pull request is part of a stack How does GitHub determine if a PR is part of a stack? Is it automatically detected so that I don't need to adjust my tooling that already creates c…

When you're using the UI to open a PR, if you set the base to a branch that has an open PR there'll be an "Add to Stack" option: https://github.github.com/gh-stack/guides/ui/#step-2-create-... Stacks require users to explicitly indicate that they are opening a PR that should be part of a stack.

It's very confusing that the "quick start" guide says the CLI is a requirement, when it's apparently not. This UI flow is exactly what I want! Thank you!

Re: GitHub Stacked PRs

#528

Post by strokirk »

riffraff wrote: post #330
dathanb82 wrote: post #226

Earlier quoted context omitted.

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

Wouldn’t it be easier to do those as stacked PRs then?

Re: GitHub Stacked PRs

#529

Post by ctdinjeu3 »

jenadine wrote: post #66

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

[dead]

Re: GitHub Stacked PRs

#530

Post by philwelch »

pierrekin wrote: post #488
philwelch wrote: post #455

Earlier quoted context omitted.

Squashing is fine if you’re just making a mess of temporary commits as you work and you don’t want to keep any of those changes separate in master, but that’s not a useful review workflow. A lot of times I’ve built a feature in a way that decomposed naturally into e.g. two commits: one to do a preparatory refactor (which might have a lot of noisy and repetitive changes, like changing a function signature) and another…

Yes what you’re describing is literally the thing GitHub has built but instead of having to make a bunch of compromises, there is dedicated UI and product metaphor for it. Some examples of compromises: You can’t merge partially merge a large “review commit by commit” PR so you are forced to wait until it is all ready to merge.

> You can’t merge partially merge a large “review commit by commit” PR so you are forced to wait until it is all ready to merge.

These are two different use cases. I thought we were talking about the one where a set of changes is more readable commit by commit but you still want to merge the whole set of changes, not the one where the change is too big to review and merge at once so you have to break it up into multiple reviews. The latter use case is more rare—frankly, it’s a bit of a red flag otherwise—and wasn’t difficult anyway.

Microsoft didn’t need to build anything because it was already built into Git. The only problem is, if people knew how to use Git, Microsoft couldn’t lock them into a proprietary version control platform.

Post reply on HN