Why not have everyone create their PRs against a feature branch instead of master, and merge the feature branch into master when the project is done?

I don't mean multiple PRs for the same repo, I mean multiple PRs across multiple repos.

Well, if you practice trunk based development, (which at most, is short lived branches that aren't really suppose to last beyond 72 hours for development purposes), its not always best practice:

https://trunkbaseddevelopment.com/

The heart of this being this point: sometimes the workflow of the team demands different ways of thinking about it, and its nice to have that flexibility.

Edit: worth noting also, this does something for those of us using this methodology (I am a big promoter of trunk based development with ruthless purging of short lived feature branches)

Opening WIP PR allows everyone to see several things:

1. what issue is being worked on 2. that it is claimed by someone 3. When that issue was started to being worked on 4. The intentions in solving the issue (if done right)

Those are real wins.

I wonder if the hub client will get a open draft PR option soon.

One of the benefits of mono-repos

we have ~10 actively developed independent repositories, and this is one of the primary reasons I wish we had a mono-repo

Do you mean link multiple PRs across multiple repos? You can already merge multiple commits together in the same PR, in a single repo, of course. via branches.

If so, this can't be done within git, since the overall container is a single repo.[1] There is no atomicity or even coordination between repos. You can get loose coordination though via integration with an issue tracker like jira. The tracker links multiple PRs across multiple repos into a single meta-merge. But you aren't going to get "simultaneous merge" in the sense of a single atomic cross-PR and cross-repo commit.

[1] One of the things that is awful with github [not git itself], is that all your controls such as commit rules, privileges, visibility, have the granularity of the entire repo. Even though awful, this is the right approach considering that many git restrictions are per-repo, eg branches. vs perforce, eg

Yes, I'm talking about coordinating PRs against multiple repos. Obviously, this isn't a git feature, this is something that Github would need to do, just like issues/webhooks/comments are not git features.

This is one of the reasons cited for monorepos, you can make a single atomic commit/PR that changes some API, and the consumers of that API.

As it is now, you end up writing a warning comment to merge some other PR at the same time and hoping your reviewers read it.

or use a capable issue tracker. honestly, any project where you need to do such coordination needs such an issue tracker anyway.

I think the way git supports this workflow currently is to have a super-repo containing all the other repos as submodules. You can bundle all those changes together as updates to the submodule references in a single PR.

In my experience, this is like waltzing barefoot with Satan.

Gerrit supports this feature. You just add "Depends-On: changeID" in your commit message.

Phabricator can do it, you can add child revisions to any differential. It's quite nice.