-
Notifications
You must be signed in to change notification settings - Fork 130
Allow to reopen pull requests after a force push #361
Comments
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 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 What did GitHub say in their reply? |
From the OP:
|
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.) |
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.) |
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. |
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:
But I still don't understand what is the difference between that case and the case where the PR is open.
The text was updated successfully, but these errors were encountered: