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 9 hours ago | parent | next [-]

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 9 hours ago \| parent [-]
		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.

▲

throwaway9980 9 hours ago | parent | prev | next [-]

Who hurt you?

▲

dpcx 9 hours ago | parent | next [-]

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

	▲	8 hours ago \| parent [-]
		[deleted]

▲

simplyluke 9 hours ago | parent | prev [-]

Microservices, by the sound of the original comment

▲

Arbortheus 9 hours ago | parent [-]

Microservices without a monorepo is hell

	▲	Yokohiii 8 hours ago \| parent [-]
		They've opted for critical damage.

▲

ameliaquining 9 hours ago | parent | prev [-]

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 7 hours ago \| parent [-]
		> 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.