René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Design: separate a stacked PR's merge target from its base","articleBody":"From [Overview / What Is a Stack?](https://github.github.com/gh-stack/introduction/overview/#what-is-a-stack):\n\n\u003e A pull request stack consists of two or more pull requests in the same repository where:\n\u003e\n\u003e - The first (bottom) pull request targets the main branch (e.g., main).\n\u003e - Each subsequent pull request targets the branch of the PR below it.\n  ```\n     ┌── feat/frontend     → PR #3 (base: feat/api-endpoints)  ← top\n    ┌── feat/api-endpoints → PR #2 (base: feat/auth-layer)\n   ┌── feat/auth-layer     → PR #1 (base: main)               ← bottom\n  main (trunk)\n  ```\n\n[endquote]\n\n_Merging to the base branch is fundamentally wrong for this._ In your example here, `api-endpoints` is not logically *part of* `auth-layer`, so should not merge to it. You should separate \"base\" and \"target\" (e.g. `main`, `super-feature`, etc). Normally all branches in a stack will merge to the same target.\n\nYou already track \"target\" as distinct from base - your own [Overview](https://github.github.com/gh-stack/introduction/overview/#what-is-a-stack) states each PR is evaluated for rules and protections using \"its final target branch (e.g., `main`), not the branch it directly targets.\" So the concept exists; it's just confined to rule evaluation and discarded everywhere else. Promote it to a first-class merge destination.\n\nResult should be something like:\n\n```\n$ git log --all --graph --decorate --pretty=oneline --abbrev-commit\n*   043bf03 (HEAD -\u003e main) Merge pull request #2 from username/feat/2\n|\\\n| * 88624f8 (feat/2) Feature 2\n* | 39f3460 Merge pull request #1 from username/feat/1\n|\\|\n| * 0f1e961 (feat/1) Feature 1\n|/\n* 04a9dac Initial commit\n```\n\nRelated, I made the [same point to Git Butler](https://github.com/gitbutlerapp/gitbutler/issues/10936), but they're constrained by the existing GitHub implementation. But you are GitHub, now deciding the next implementation - not constrained.\n\nAlong with this, the implementation should display and enforce \"below\" branches in the stack as prerequisites. `feat/2` should be blocked from merging until `feat/1` has merged. You'll have to make this explicit, instead of just a side effect of merging to the base branches.","author":{"url":"https://github.com/bmcdonnell-fb","@type":"Person","name":"bmcdonnell-fb"},"datePublished":"2026-06-29T20:36:19.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":0},"url":"https://github.com/157/gh-stack/issues/157"}