CODEWITHSUNDEEP
gitgithub
jeromefroe
jeromefroe

Reputation: 1395

Can you use a branch in a forked repository as the base branch for a Github PR against upstream?

So I recently read this blog post on stacked diffs for Github PR's and have been trying to follow it. I've run into a snag though for a repo I'd like to make a few stacked PR's against for which I don't have access to the upstream repo so I can't push any branches to it. I created an initial branch in my forked repo and opened up a PR against master of the upstream repo. I then created another branch with that previous branch as my base. I made some code changes and I wanted to open a second PR with my first branch as base but I can only do so against my own forked repo and not the upstream repo. Has anyone ever run into a similar problem? In the past I've had access to the upstream repo so this hasn't been a problem because I could push my branches to upstream. I'm just not sure of a possible workaround for the case where you don't have access to upstream.

Upvotes: 1

Views: 181

Answers (1)

VonC
VonC

Reputation: 1326832

I then created another branch with that previous branch as my base. I made some code changes and I wanted to open a second PR with my first branch as base but I can only do so against my own forked repo and not the upstream repo

Yes, that is expected: you compare your work against an upstream branch, and yours has not yet been merged in the original repo: it exists only in your fork.

A workaround is to:

  • create your second branch from upstream/master (meaning from a branch of the original repo)
  • git cherry-pick (which is to say duplicate) the commits from your first branch,
  • add your work for your second branch and push that to your fork
  • make your PR from your fork

As the OP concludes:

it didn't quite accomplish what I had in mind as the PR included the changes from the first branch.

I believe the problem is ultimately that Github doesn't let me make the base of a PR against upstream a branch in a forked repo for which a PR is already open.

This of course makes sense as that branch hasn't been merged into upstream yet and so doesn't exist in the upstream repo, but it does seem to proscribe the possibility of stacked pull requests for an upstream repo which one cannot push to.

I agree: a PR, ideally, is meant to be applied independently of other PRs: the maintainer pick and chose which ones to accepts, which ones to rejects.

What I described above is a workaround, but ultimately is not a best practice.

The OP adds:

What I decided to do was open my first PR against upstream master and my subsequent PR's against the previous branch in my forked repo.
Then, as one PR lands, I can easily change the base branch for the next PR to be upstream master which now includes the changes from my previous PR.

That is indeed the correct way to update an existing PR against an updated origin/master (which now includes another merged PR)

Upvotes: 2

Related Questions