by inetknght 4 days ago

Cool. Now let me do it across multiple repos. I often end up with 10 or 20 PRs across a half dozen repos that need to be merged in specific order.

whalesalad 4 days ago | [-1 more]

For sure. If you are in a monorepo this solution works but if you have distinct microservice repositories it would help to coordinate pr #827 on repo-A and pr #1092 on repo-B are related and need to ship in a certain order.

ZeWaka 4 days ago | [-0 more]

Exact problem we've run into at work. We've ended up having to write external merge coordination in order to not break our dev deployments.

ameliaquining 4 days ago | [-1 more]

How would that work? Commits in different repos aren't ordered relative to one another. I suppose you could have a "don't let me merge this PR until after this other PR is merged" feature, but you could do that with a GitHub Action; it doesn't really need dedicated backend or UI support.

inetknght 4 days ago | [-0 more]

> How would that work?

In practical terms: I manually write a list of PRs, and maintain that list in the description of each of the PRs. Massive duplication. But it clearly shows the merge train.

throwaway9980 4 days ago | [-5 more]

Who hurt you?

dpcx 4 days ago | [-1 more]

Their manager who suggested that everything be a microservice, but everything depends on each other.

4 days ago | [-0 more]
[deleted]
simplyluke 4 days ago | [-2 more]

Microservices, by the sound of the original comment

Arbortheus 4 days ago | [-1 more]

Microservices without a monorepo is hell

Yokohiii 4 days ago | [-0 more]

They've opted for critical damage.