Allow to reopen pull requests after a force push

If I close a pull request, force push to the branch, and then try to reopen it, the "Reopen pull request button" is deactivated and the on hover tooltip says "The XXX branch was force pushed or recreated".

Why does it behave like this, considering that you can force push open pull requests and it all works as expected?

This is a reasonably common use case, e.g. if I make a pull request, notice it is not good enough, close not to waste reviewer's time, then update.

Sample: preservim/vim-markdown#176

Update: GItHub replied:

We're blocking the pull request reopen if the current head isn't a descendant of the stored head sha (which is what the head was when the pull request was closed). We are not allowing the reopen in that case, because there is no good way to tell what changes have happened while a pull request was closed and the head branch has changed.

But I still don't understand what is the difference between that case and the case where the PR is open.

Yeah, that's weird. I can't think of any reason why that should happen. Maybe it's supposed to force people to keep from re-using pull requests for multiple merges (like a pull request can only be merged once)?

Did you email GitHub about this? What was their response?

@stuartpb

@stuartpb I've emailed them as usual, but no reply so far. When they do reply I'll update.

github replied

👍 I don't understand how this is different either. I've literally done hundreds (if not thousands) of force pushes to PRs, without issue, but if it's closed a force push seals it shut forever no matter what.

+1 on this issue, any resolution?

@cirosantilli

@cirosantilli What did GitHub say in their reply?

From the OP:

We're blocking the pull request reopen if the current head isn't a descendant of the stored head sha (which is what the head was when the pull request was closed). We are not allowing the reopen in that case, because there is no good way to tell what changes have happened while a pull request was closed and the head branch has changed.

@cirosantilli

I think their point is that Github tracks a reflog of every HEAD change while the PR is open (for... some reason?), but doesn't do this tracking when the pull request is closed, so they can't construct a history between what the branch's HEAD was when the PR was last open and what the HEAD of the PR's branch is now.

I agree with @cirosantilli that this is ridiculous, since they don't use this kind of history tracking anywhere (at least not in the public-facing UI) or even reference old HEADs except in "outdated diff" comments, which are already associated to a specific commit and point in time when the comment is posted (unless they're only associating the comment with a blob position and a point in time and then reconstructing the commit the comment would have been on post-facto using forensics on the aforementioned reflog, which, if so, is a hack, and needs to be refactored).

And, if I understand their complaint correctly, it should be possible to work around this by saving the PR's branch's current HEAD, re-force-pushing the HEAD it had when the PR was closed, re-opening the PR, then re-force-pushing the HEAD it was at before re-opening. (Which is completely stupid to have to do.)

@cirosantilli

This would be useful to have (and I'm sure it used to work).

I think the use case that @cirosantilli has is quite common. After receiving feedback on a pull request it's nice to be able to close it to indicate that it's not ready to be merged, and then modify the commits and force push to keep the history tidy.

The practice of updating PRs in place with force pushes should be reconsidered anyway. It was inevitable that practices which amount to telling lies for a more palatable history would carry consequences (just like in real life.)

It's not just "telling lies for a more palatable history".

let's not flamewar to rebase or not to rebase.

It's all just electrons moving around inside our CPUs in the end.

😄

Yes, force-pushing the original HEAD doesn't seem to help, the PR still can't be reopened. From our own fork GH should be assuming that we know what we're doing.

I was in similar situation today i.e. used "Merge Pull Request" button which by default merge the changes into target branch and close the PR. I later discovered a bug in testing which I wanted the original developer to fix. I wanted a way to reopen this PR so that more commits can be added to this same PR but could not as there is no button for reopening the PR.

GitHub reply:

We're blocking the pull request reopen if the current head isn't a descendant of the stored head sha (which is what the head was when the pull request was closed). We are not allowing the reopen in that case, because there is no good way to tell what changes have happened while a pull request was closed and the head branch has changed.

However, they don't seem to allow this even if you force push and return to the same sha. That seems like it should be allowed, no?

Workaround. Pushed the branch (oops its not on the same commit). Steps to get PR reopened.

Delete the branch using the button in the GitHub PR.
Move the branch back to where the last PR sha is locally.
Push the branch again.
Reopen the PR.
Now rebase and what not to your hearts content.

It's a bit tedious, but it will get you to the desired outcome.

Any plans to fix this github? Extremely frustrating.

what is the point to close and cannot reopen a PR when you can create that one again but as a new one?
i mean it is just something that is counter productive and PR polluting. losing comments and code reviews and start it again or just referencing it.

Anyone knows WHY they put this policy?
It is limiting how people can work within their repos.

Counter-proposal: Silently delete PR and retain commit comments after a force push without an ability to manually delete it.

why force me to jump through all these hoops when i should just be able to click on the reopen button?

this is so obvious it has to be against someone's belief system, philosophy, or some other nonsense.

Force pushing the previous head commit, reopening, then force pushing the new commit worked fine for me. No gymnastics needed.

This is ridiculous. I closed a PR, and I needed to retroactively sign my commit, so I rebased and force pushed, and then I ran into this.

I was able to get back to the state where the PR could be re-opened by force-pushing the branch at the state when it was closed.
To get there I used git reflog and git reflog --date=iso to find the SHA1 of the last commit before the close, then the syntax
git push origin <SHA1>:<branch_name_on_origin> --force
where origin is my github repository's fork of the main repo (I closed the pull request on the main repo).

This might bet a good opportunity for a lil workflow tweak.

I hit this situation where I had a PR 2 based off the branch A which was under development in another PR 1. I was staging my work to roll into a parent branch that A would ultimately roll into and likewise for branch B in PR 2 when work on A wrapped up. I merged and deleted PR 1, and came to find that PR 2 was closed because it was targeting a deleted branch. Trying to reopen PR 2 yieled: The A branch has been deleted.

I initially targeted PR 2 off of A to better track the incremental ideas it captured without waiting for A to roll in first and let code review happen in parallel. It would serve us well if GitHub had a notion of "ultimate base" to fall back on whenever the active base is deleted. That would create a nice workflow, but maybe there's something flawed in my thinking that's shortsighted on something.

@jxramos

@jxramos your development workflow makes total sense to me. I double the idea of a default-base, it would indeed come in handy in those cases.

In the meantime, you can rely on Github's REST API, and curl-up the pulls that are based on your branch before making the remote branch deletion. Along the lines of:

if [ $(curl https://api.github.com/repos/$repo/pulls?base=$branch | jq 'length > 0') = 'false' ];
then
    git push origin :$branch;
else
   echo "won't delete because $branch branch is a pulls base";
fi

@Rob Miller commented on December 3, 2019 1:06 PM:

I was able to get back to the state where the PR could be re-opened by force-pushing the branch at the state when it was closed.
To get there I used git reflog and git reflog --date=iso to find the SHA1 of the last commit before the close, then the syntax
git push origin <SHA1>:<branch_name_on_origin> --force
where origin is my github repository's fork of the main repo (I closed the pull request on the main repo).

If for some reason you lost the reflog, I found that you can still reconstruct the PR history via a GraphQL query on GitHub's v4 API, e.g.

{
  repository(name: "straight.el", owner: "raxod502") {
    pullRequest(number: 564) {
      timelineItems(last: 10, itemTypes: HEAD_REF_FORCE_PUSHED_EVENT) {
        nodes {
          ... on HeadRefForcePushedEvent {
            afterCommit {
              url
            }
            createdAt
          }
        }
      }
    }
  }
}

If you feed that into docs.github.com/en/free-pro-team@latest/graphql/overview/explorer, you get:

{
  "data": {
    "repository": {
      "pullRequest": {
        "timelineItems": {
          "nodes": [
            {
              "afterCommit": {
                "url": "https://github.com/raxod502/straight.el/commit/fae0871e878d3cbc34a93c5f3c7faa300093df1f"
              },
              "createdAt": "2020-08-30T14:12:49Z"
            },
            {
              "afterCommit": {
                "url": "https://github.com/raxod502/straight.el/commit/ee29a1e535fa78002b08d82f98c0369330339945"
              },
              "createdAt": "2020-08-30T14:50:25Z"
            }
          ]
        }
      }
    }
  }
}

Navigation Menu

Repository navigation

Allow to reopen pull requests after a force push #361

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Allow to reopen pull requests after a force push #361

Description

Activity

stuartpb commented on Feb 25, 2015

cirosantilli commented on Feb 25, 2015

cirosantilli commented on Feb 27, 2015

jayphelps commented on Apr 2, 2015

kenbier commented on Jun 2, 2015

nhooey commented on Jun 22, 2015

stuartpb commented on Jun 22, 2015

stuartpb commented on Jun 22, 2015

stuartpb commented on Jun 22, 2015

alexmuller commented on Jul 2, 2015

paulp commented on Jul 11, 2015

stuartpb commented on Jul 11, 2015

cirosantilli commented on Jul 11, 2015

mtbc commented on Jan 6, 2016

shailendrabirthare commented on Feb 12, 2016

jakirkham commented on May 13, 2016

jakirkham commented on May 13, 2016

kieranmaine commented on Jan 29, 2017

Raffaello commented on Jun 29, 2017

erkinalp commented on Jul 5, 2017

Spongman commented on Feb 1, 2018

FeepingCreature commented on Jun 29, 2018

virtualdxs commented on Oct 26, 2018

rob-miller commented on Dec 3, 2019

jxramos commented on Feb 25, 2020

lajarre commented on May 5, 2020

aspiers commented on Dec 16, 2020

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions