Feature Request: Support DAG's

[d4hines]

Hi,
Suppose I'm working on big feature A. Along the way I make small improvements B, C, and D. I can structure a stack like:

A -> B -> C -> D-> main

But suppose B, C, D are all orthogonal to each other. The above structure imposes an order that isn't necessary and may not even make sense (the diff on github will compare C with D, but we'd like to compare C with main. If D is controversial, review may take a long time, but B and C might be able to be quickly reviewed and merged, minimizing the distance of A to main (which is the end goal).

What I would like is a DAG:

              A
          /   |   \
        B     C     D
         \    |    /
            main

This would allow us to review and merge with maximal "concurrency".
I'd like gh-stack to keep track of this dependency graph and automatically do the required rebasing on changes.

Is this possible? None of the existing stacked git tools seem to support this so I'm wondering if there is some fatal flaw.

[luqven]

GitHub’s single-parent PR model makes true DAG workflows awkward, regardless of tooling.

While Git itself supports DAGs, GitHub PRs require each change to have exactly one base, forcing DAG-shaped work into linear or tree-like structures.

This leads to several issues when trying to maintain the DAGs:

• Rebase complexity: When a shared dependency changes, all downstream PRs must be updated. If sibling PRs overlap, rebasing them independently can surface conflicts, and tools must impose an arbitrary ordering.
• Ambiguous diffs: In a DAG, a PR may logically depend on one change but not another. GitHub’s single base makes it unclear what the diff should be computed against as dependencies evolve.
• Serialized landing: Even if PRs can be reviewed in parallel, they must land sequentially. Some merge orders may temporarily break tests, reducing effective concurrency.
• Workflow linearization: While Git is a DAG, GitHub workflows strongly bias toward linear histories via rebases and merge queues, making concurrent dependent changes harder to manage.
• State complexity: Although only interacting PRs affect merge outcomes, managing those interactions is still more complex than working with a single linear stack.

Tools like Graphite address this by collapsing DAGs into explicit stacks, treating one path as the trunk at a time. This sacrifices some expressiveness but significantly reduces ambiguity and operational complexity.

You could achieve the same with gh-stack, but again you have to "collapse" the DAG and treat each path a trunk.

[luqven]

For now I'm going to go ahead and close this issue, but happy to re-open it if there's more interest in the discussion.