Hacker News Reader

Comment by IshKebab | Hacker News Reader

Lack of investment more like. There are a ton of simple and obvious bugs that have persisted well before the AI crazy, e.g. this annoying bug from 2021: https://github.com/orgs/community/discussions/6874

This one is almost a one-line change (technically they need an extra flag in the YAML but that's hardly difficult): https://github.com/orgs/community/discussions/12882#discussi...

That said, I still think Github is fine, and you can't argue with free CI - especially on Windows/Mac. If they ever stop that I'll definitely consider Codeberg. Or if Codeberg gets support for stacked PRs (i.e. dependencies between PRs), then I'm there! So frustrating that Github doesn't support such an obvious workflow.

View on HN

Not spending on maintenance is bad.

Not spending on maintenance and spending gobs on something many people don’t want is far worse. It says we have the money, we just don’t give a fuck.

Isn't this SOP of Microsoft since forever? Tons of papercuts which really hurt, and tons of features nobody wants?

I think this is the natural outcome of "chasing points" mechanic inside Microsoft.

For my money, the scorpion is halfway across the river and y’all are about to become the frog. I haven’t touched a windows machine in 15 years and I’d really like to continue that streak to the grave. Gaben is working hard to become my new favorite tech person by trying to claw gaming off of the PC. I really hope he wins.

The evidence of AI failure is all this low hanging fruit maintenance fixes users are begging Microsoft to fix and these AI agents are not fixing them. AI was going to 10x engineers or something right? Why isn’t GitHub getting better with all this AI help?

> So frustrating that Github doesn't support such an obvious workflow.

It kind of does.

I used this a lot in several jobs to work in dependent tickets in advance. Just make another branch on top of the previous (a PR to the other PR branch).

People could review the child PR before the parent was merged. And it requires some less than trivial git knowledge to manage effectively, but nothing extraordinary. Any solution for stacked PRs based on git would also require it (or a custom tool).

I think I'm on their side on this one. From git perspective, it works just as I expect. Something else probably belongs to JIRA or project management instead.

That feels like the opposite of what I think stacked PRs are? Like someone will open PR #1 for one feature, and then PR #2 into the PR #1 branch, but it doesn't make sense without knowing the context of PR #1 so that gets reviewed first - and then when that PR gets merged, the second one gets automatically closed by GitHub?

PR#1: dough PR#2: toppings

You first send PR#1, then PR#2 on top of the first one.

The diff for PR#1 will show dough stuff. The diff for PR#2 will show toppings in relation to dough.

People can review them asynchronously. If you merge PR#1, PR#2 will automatically target main (that's where dough went) now.

In this arrangement, I use to cross-mention the PRs by number (a link will exist in both). I also like to keep the second one draft, but that depends on the team practices.

I don't understand why you would close the second PR when the first gets merged. It should lose the dependency automagically, which is exactly what happens if you branch correctly.

> The diff for PR#2 will show toppings in relation to dough.

The problem is the diff for PR#2 will show dough and toppings all mixed together. Unless you go into the commits view, but that's super tedious and it's easy to lose comments in there.

It's kind of frustrating because there's very little required to make this work. All you really need is for Github to detect `Depends on #1` like it detects `Fixes #123`, and then a) use the HEAD of #1 as the diff based for #2, and b) block merging #2 until #1 is merged.

It's really not that complicated but I'm not holding my breath.

What do you mean by "mixed together"?

PR#2 will show only what changed between dough and toppings.

If you merge it, it will become part of PR#1. You turned the dependency into a single block.

So, if you don't want to mix, you should merge the dependency (dough) first to main (or whatever is your target).

Codeberg probably also supports the same thing, it's a git thing not a GitHub thing. That's why I'm saying it works exactly as expected. Git alone already supports dependencies, and GitHub just follows it.

To block the merge, you can make a workflow that turns PRs with dependencies into drafts. However, as it is a merge from one PR into another, I don't see the reason to. You can easily de-merge them if you need.

From the looks of it, it seems that you are branching at the wrong point, and creating two PRs to main, one of them containing duplicates. That's not what I suggested.

Reply on news.ycombinator.com