[IshKebab]

It blows my mind that Github still doesn't support stacked PRs. Do they never do work that depends on an open PR? Like, as soon as they open a PR they're like "right, better stop doing anything until it's merged"?

The file priority thing is a great idea too. That would be even more useful for search. The number of times I'm searching for something on Github and it just shows me a gazillion tests.... Yeah you can look up their advanced search syntax and exclude them probably, but it's always a hassle.

[jmalicki]

You can manually stack PRs by making the merge target another branch.

The workflow just makes it a pain, since you have to manually rebase in both the branch and the UI after the original PR merges.

[IshKebab]

That doesn't work if the base and PR branch are in different repos, which is the most common way of doing things in Github.

[justinclift]

When the base and PR branch are in different repos, it'll still work if the PR branch's repo is a fork of the base one.

[IshKebab]

No it doesn't. Here's the situation. You have an upstream repo github.com/fancyproject/fancyproject. You fork it to github.com/yourname/fancyproject. You make a branch `feature_0`, push it to yourname/fancyproject. Make a PR.

Next you create another branch `feature_1`, based on `feature_0`. You push `feature_1` to yourname/fancyproject. There is now no way to make a PR for `feature_1` that includes only the changes from feature_0 to feature_1. You can't do it because when you create the PR (in fancyproject/fancyproject) you can't select `feature_0` as a base branch because that branch doesn't exist in fancyproject/fancyproject.

[justinclift]

Interesting.

Are you're saying that you'd want the commits for `feature_0` through `feature_1` to be in the PR (to the upstream fancyproject repo), and you'd want it to exclude the commits in the range from the fork commit through to `feature_0`?

While that's a very edge case scenario, I think (theoretically) you'd be able to do it if you first cherry-pick the commits you want onto a new branch based upon the same original fork commit that your repo forked from.

ie ensure the PR branch you create doesn't include any commits you want excluded

That should pretty much guarantee the PR goes smoothly. In theory. :)

[jmalicki]

> Are you're saying that you'd want the commits for `feature_0` through `feature_1` to be in the PR (to the upstream fancyproject repo), and you'd want it to exclude the commits in the range from the fork commit through to `feature_0`?

That's what stacked PRs are

You can review just the addition, knowing what it is building on top of.

[steveklabnik]

GitHub is putting stacked PRs into private beta around now, actually.

[esafak]

link?

[bewuethr]

https://github.com/github/roadmap/issues/1218 is the tracking issue for it

[l72]

I just want the simple feature of PRs updating when the target branch changes. For example, say I have two tickets: T-100 and T-101. Both are targeting main, but T-101 builds on top of T-100. I put up a PR for the T-100 branch against main, and put up a PR for the T-101 branch against main.

The T-101 PR can't really be reviewed yet, since you are looking at changes from both T-100 and T-101 (because T-101 was based on T-100).

Ideally, after T-100 is reviewed and merged, the T-101 PR would automatically update to show only the T-101 changes. But it doesn't. You have to manually rebase or merge main and push changes to the branch to get it to update. It would be great if GitHub handled this automatically.

[IshKebab]

Locked... I'm like 40% sure they'll mess this up in some way that makes it completely useless.

[steveklabnik]

https://x.com/jaredpalmer/status/2019817235163074881

(this was a follow-up to the initial announcement months ago, also made via X)

[IshKebab]

Ah nice! I hope this actually works across repos rather than just being nicer UI for the existing functionality.