Stacked branch PRs set wrong GitHub target branch (and repo?)

[bmcdonnell-fb]

I'm very interested in what GitButler is doing - particularly the stacked branches - especially the part in the PRs where only the commits since the parent branch are shown. (Also the virtual branches are quite intriguing.) But GitButler seems to be abusing the PR target branch ("base" repo/branch), which has me thinking you haven't quite solved the problem - at least not for use with GitHub.

IMO, the goal is to merge the stacked features sequentially into (typically) the main or master branch in the upstream repo. But it looks like GitButler is setting the target to the parent branch (in the child repo).

Is this a workaround to make it only show the desired commits in the list? IMO it's problematic in terms of workflow and miscommunication.

From your demo, with my annotation

Since feature-2-gb is not logically part of feature-1-gb, it should not be merged into feature-1-gb.

Blue is as expected; red is not.

What I expect to see

Expect to merge to main (purple).

A more real world example

Both features get PRs/merged to the target branch in the upstream repo, not the originating repo.

Additional info

Might it be preferable to invert the list order in the PR description? (i.e. List the patches/PRs in the order in which they are applied, like git rebase --interactive; not git graph order.)

[bmcdonnell-fb]

From your docs, Stacked Branches:

In order to show only the expected Files changed and Commits for PRs in a stack, each PR is created to target the branch below it in the stack. This is true for all but the bottom branch in the stack, which targets the default branch of the repository as usual.
...
This of course does not mean that a Pull Request should be merged into its parent. When the bottom branch is merged on GitHub, if the PR branch is deleted, GitHub will automatically update any PRs that used to target it to target the default branch instead.
...
If the newly merged branch from the bottom of the stack is not deleted, the next PR in line will still target it and there is a risk of accidentally merging it into the now out of date branch. For this reason it is highly recommended to enable on GitHub the automatic deletion of branches after merging.

I'm glad to see that you're aware that the parent branch is not the appropriate target. But AFAICT this means you're relying on an implementation quirk of GitHub for your stacked branches to display almost correctly in their PRs. (Also relying on users to (auto)delete their merged branches, which may not be desirable.)

All that makes this feature of GitButler brittle and prone to breakage, especially if GitHub changes that implementation detail, right?

Any chance @schacon can get @github to implement some proper hooks for stacked branch PRs, with correct targets?