GitHub advises "Force pushing can corrupt your pull request." Why?

Question

In https://help.github.com/articles/about-pull-requests/ , GitHub has a note reading:

Note: When working with pull requests, keep the following in mind:

[...]

• When pushing commits to a pull request, don't force push. Force pushing can corrupt your pull request.

I don't understand the reasoning for this -- in the past I have routinely force-pushed amended commits to branches with an associated open PR and never seen any branch or PR UI corruption issues.

I am aware that force-pushing makes it harder to work with co-workers on the same branch -- but to me that does not really meet the definition of a "corrupted branch" or a "corrupted PR".

Can anyone explain what GitHub mean by this?

Lash

I would guess that you can force-push things GitHub wouldn't know how to integrate with the pull request, such as force-pushing away all the commits in the pull request. – Ennius

If there are only commits left that are also available on the base branch already, GitHub will automatically close the PR. – Lash

Answer 1

Force pushing can corrupt your pull request. It doesn't always do.

When a real force push happens, the original pull request loses one or more commits and the updated pull request may or may not bring in one or more new commits. If the changes introduced by the lost commits are not included in the new pull request, the content of files is corrupted. If the changes are kept, but the information including author/committer names, emails or dates is forged, we can also say the pull request is corrupted. These are the things that matter in a version control system. But it's not a problem if you intend to do so. Sometimes it's necessary to rewrite histories.

In your case where I guess only commit messages are amended and nothing important is lost, I believe it's the right thing to do a force push as long as you know the consequences. But it will be a problem if one does it accidentally or recklessly, especially when the pull request includes unmerged commits from other contributors.

When you really need to do a force push, you can always create a new pull request, which is much safer and keeps away annoying problems

Compatible

I guess your argument is "if your local branch is broken, force pushing will propagate that brokenness to the server," but then I still find GitHub's wording misleading: your local changes are the culprit, not the force push in itself. – Lash

I think he means that the actual PR can be messed up by force pushing. For example if a change has been requested for certain lines of code, those reference might be lost if the commit in question is no longer available after a force push, because GitHub does nothing to track which commits are references by PRs when garbage collecting on their side. – Derina

Given that the PR #1234 points to a branch name foo, it's possible to git checkout foo, back it up with git tag PR-foo (or git tag PR-1234) and then git push --tags, before doing the git push --force. This should preserve the commits referenced by the pull-request code comments or change requests. – I didn't try yet, tho, but I also was bothered by this loss of history, making code-comments refer to commits not existing anymore. – Secondhand