[go: up one dir, main page]

Skip to content

Be able to move merge requests across multiple projects/forks

Issue idea came from: http://blog.ffwll.ch/2017/08/github-why-cant-host-the-kernel.html

Usecase

Pull request need to be attached to multiple repos at the same time, while keeping one unified discussion stream. You can already reassign a pull request to a different branch of repo, but not at multiple repositories at the same time. Reassigning pull requests is really important, since new contributors will just create pull requests against what they think is the main repo. Bots can then shuffle those around to all the repos listed in e.g. a MAINTAINERS file for a given set of files and changes a pull request contains. When I chatted with githubbers I originally suggested they’d implement this directly. But I think as long as it’s all scriptable that’s better left to individual projects, since there’s no real standard.

There’s a pretty funky UI challenge here since the patch list might be different depending upon the branch the pull request is against. But that’s not always a user error, one repo might simple have merged a few patches already.

Also, the pull request status needs to be different for each repo. One maintainer might close it without merging, since they agreed that the other subsystem will pull it in, while the other maintainer will merge and close the pull. Another tree might even close the pull request as invalid, since it doesn’t apply to that older version or vendor fork. Even more fun, a pull request might get merged multiple times, in each subsystem with a different merge commit.

Problem

You can already reassign a pull request to a different branch of repo, but not at multiple repositories at the same time.

Proposal

Be able to move merge requests across multiple projects/forks

Value

  • Being able to support really large projects, with advanced git flows, like the linux kernel git workflow
  • Be able to move merge requests across multiple projects/forks

CC/Call to actions