This is a metaphor bug in the UX. In git's original terminology a "pull request" (a request from a subsystem maintainer to pull new stuff -- usually from a branch named something like 3.5-staging-for-linus or whatever) is different from a "patch set" (a single submission of code from anyone, often via email with "PATCH n/m" subjects).<p>Github treats them essentially the same, which is just wrong. It's the patch set that is the unit of code review. It's just plain never correct to review a "branch", you review specific suggested changes in isolation. The idea of pulling branches is to merge already-reviewed code from different trees.
This isn't really "pinning" a pull request. The problem is not that "GitHub Pull Requests are dynamic".<p>Any branch name is just an alias for the latest commit in that branch. For example master is just an alias for the latest commit in master so you can reference that commit without the SHA1 hash. When I submit a pull request for foo/master then push new commits for foo/master, I just changed what master points to so my pull request changes. By using the commit hash you avoid the commit alias problem because new commits won't change what a commit hash references.<p>In fact, virtually anywhere you use a branch name in git or github you can also use a commit hash.
If I recall correctly, it is possible to modify a pull-request by deleting the "active" commit of the pull request on github and adding something else, i.e. if I do something like rebase -i and then a push -f (which I can, because, after all, it is my own repository I am pushing to.)
Why wouldn't they just comment on the pull request to set a history point and review from there? This allows changes while still being able to see what may have changed and why. Honestly I can't see how slinging patches by email works better.