How to send one pull request per separate commit?

Question

I forked a project. I worked on it for a bit.

I now have ten different commits, each of which is independent of the other commits. I'd like to send each individual commit as a separate pull request, to let the maintainer of the upstream choose which ones he/she wants.

I can't find an easy way to do this.

The "easiest" I can find is to create ten separate branches, and cherry-pick each of the ten separate commits into those branches, and then send a pull request from each.

That's ... not sane! (See for example how to divide one pull request into two different pull request on github )

The underlying git request-pull function supports this workflow, so is the problem here that GitHub just doesn't have a good interface to this? Am I doomed to create ten branches?

Ecumenicism

Answer 1

GitHub's Pull Requests are designed to be per-branch, not per-commit. This is deliberate:

After your pull request is sent, any new commits pushed to your branch will automatically be added to the pull request. This is especially useful if you need to make more changes.

If you want to send ten Pull Requests in GitHub you'll have to do it using ten branches. The only exception would be if you wait for each Pull Request to be merged before submitting the next one.

Poinciana

Thanks for the answer. While this may be deliberate, it is also stupid. They could have a checkbox where I choose to include or exclude specific changes. Or, if I've already sent a pull request for change N, don't also include change N when trying to send a pull request for change N+1. – Ecumenicism

FWIW: if you don't have to use GitHub, Gerrit solves this in a manner that I personally find flows better. You can merge more changes into particular commits, beacuse commits in Gerrit are identified by generated-tokens that stay in the commit message, not by git-hash. – Ecumenicism

A pull request is basically comparing two branches and merge one to another. The difference could be hundreds of commits. A branch is just a pointer to a commit. So yeah, I do believe that supporting pull requests by just specifying a commit instead of a branch will improve some efficiency in some cases. However, tradition will never changed so easily. – Toilette

@Chris: Regarding the exception, what about closing the pull request by the sender? – Rummel

Answer 2

There's a work-around suggested by Grason Koonce that amounts to:

creating successive branches for each piece, and making pull requests against the previous branch point(rather than the target branch).

Once all reviewed and accepted merge in reverse order 5->4, 4->3, 3->2, 2->1, and only then 1->master/target.

It's not pretty but it is a solution.

https://graysonkoonce.com/stacked-pull-requests-keeping-github-diffs-small/

Zahn

The link in this answer is broken, but I believe that this article describes the same workflow. – Rubescent

Answer 3

You can script it easily. Here is PowerShell, but can be adjusted for sh.

Set-StrictMode -Version Latest

$baseBranch='origin/dev'

$c=git log "${baseBranch}..." --format=%h
$i=1
foreach ($h in $c) {
  git checkout -b mypatch-$i $baseBranch
  if ($LASTEXITCODE -ne 0) { throw $LASTEXITCODE }
  git cherry-pick $h
  if ($LASTEXITCODE -ne 0) { throw $LASTEXITCODE }
  ++$i
}

# verify state before push
pause

# `git remote get-url my` can be used to automate this 
$url='https://github.com/user/repo/pull/new/mypatch-'
# $url="https://gitlab.com/user/repo/-/merge_requests/new?merge_request[source_branch]=mypatch-"

foreach ($n in 1..$i) { 
  # push to your fork
  git push my mypatch-$n
  # start browser to create PR or use gh-cli to create PR automatically
  start $url$n
}

Derision