Yes it will be coming! The reason it's taking a bit longer is because of the automated rebase that happens after you merge part of a stack. There are some legitimate security concerns because of this so multi-fork stacks (a stack which includes multiple different forks) are probably out of the question for now.
We will support a stack that is fully contained within a single fork, where the entire stack targets the original repo.
For example, a contributor who has a fork (user/buzz) of the original repo (org/buzz) could create the following stack:
haha, what if you add a filter that hides merge commits?
i appreciate that you are trying to make it possible for people who vibe code solutions to problems to get code merged by people who have made GitHub their lifestyle. but surely you see how, in my framing there, the people who are worried about how their history "looks" are the problem
We will support a stack that is fully contained within a single fork, where the entire stack targets the original repo.
For example, a contributor who has a fork (user/buzz) of the original repo (org/buzz) could create the following stack:
``` frontend → PR #3 (base: user/buzz:api-endpoints) api-endpoints → PR #2 (base: user/buzz:auth-layer) auth-layer → PR #1 (base: org/buzz:main) org/buzz:main (trunk) ```