Feature request: Dependent Pull Requests

[mcepl]

What problem would this solve?

Many development workflows require one pull request to be merged before another can be merged.

Examples:

Same repository

PR #101: Introduce API changes
PR #102: Use the new API

PR #102 should not be merged until PR #101 is merged.

Cross-repository

libfoo!100: Release libfoo 2.0
appbar!50: Update appbar to use libfoo 2.0

The application update depends on the library update even though they are in different repositories.

This is common in:

• package maintenance
• coordinated releases
• monorepo alternatives
• multi-repository projects

What do you propose?

Allow a pull request to declare dependencies on one or more other pull requests.

Example:

Depends on:
- owner/repo#123
- another/repo#456

The UI should display:

• dependencies
• reverse dependencies ("blocked by this PR")
• dependency status

Example:

Dependencies

✓ owner/repo#123 (merged)
○ another/repo#456 (open)

Merge gating

Optional repository setting:

Block merging pull requests with unresolved dependencies

When enabled:

Merge blocked:
This pull request depends on owner/repo#123,
which has not been merged yet.

Relationship to stacked pull requests

Dependent pull requests can also be used as a foundation for stacked PR workflows.

For example:

PR #101
  ↓
PR #102
  ↓
PR #103

can be represented naturally using dependency relationships.

However, the feature is useful even without any stacked-PR-specific UI because it also supports cross-repository workflows that are not based on Git branch ancestry.

Use cases

Package maintenance

A package update may require another package update to be merged first.

Example:

libfoo update
    ↓
appbar update

Coordinated releases

Changes spanning multiple repositories can be merged in the correct order.

Stacked development

A sequence of pull requests can be reviewed and merged incrementally.

Benefits

• Better support for multi-repository projects.
• Better support for package maintenance workflows.
• Foundation for future stacked-PR functionality.
• Clear visibility of merge prerequisites.

[mcepl]

#38232 is probably required for this.

[hiSandog]

Dependent PRs would need a few guardrails to avoid turning into an implicit merge queue. The design should probably cover cross-repo dependencies, cycles, branch deletion/force-push behavior, and whether blocked PRs still run CI. Even a first version limited to same-repo dependencies with cycle detection and a visible blocked state would solve many workflows without overcommitting the model.