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.

▲

hinkley 3 hours ago | parent | next [-]

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.

	▲	jiqiren 2 hours ago \| parent \| next [-]
		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?
	▲	bayindirh 3 hours ago \| parent \| prev [-]
		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.

▲

gaigalas an hour ago | parent | prev [-]

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

▲

sevenseacat an hour ago | parent [-]

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?

	▲	gaigalas an hour ago \| parent [-]
		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.