Skip to content
This repository has been archived by the owner on Nov 18, 2021. It is now read-only.

Allow to reopen pull requests after a force push #361

Open
cirosantilli opened this issue Feb 21, 2015 · 27 comments
Open

Allow to reopen pull requests after a force push #361

cirosantilli opened this issue Feb 21, 2015 · 27 comments

Comments

@cirosantilli
Copy link
Collaborator

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.

@stuartpb
Copy link

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?

@cirosantilli
Copy link
Collaborator Author

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

@cirosantilli
Copy link
Collaborator Author

github replied

@jayphelps
Copy link

👍 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.

@kenbier
Copy link

kenbier commented Jun 2, 2015

+1 on this issue, any resolution?

@nhooey
Copy link

nhooey commented Jun 22, 2015

@cirosantilli What did GitHub say in their reply?

@stuartpb
Copy link

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.

@stuartpb
Copy link

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).

@stuartpb
Copy link

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.)

@alexmuller
Copy link

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.

@paulp
Copy link

paulp commented Jul 11, 2015

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.)

@stuartpb
Copy link

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

@cirosantilli
Copy link
Collaborator Author

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

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

😄

@mtbc
Copy link

mtbc commented Jan 6, 2016

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.

This was referenced Jun 19, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests