You’re essentially proposing what the blog post proposes, with the addition of adding a comment referring to the PR branch’s old HEAD. However your concern about commit A being garbage-collected was spot on – this is indeed a serious problem which I documented in https://github.com/isaacs/github/issues/997 and other issues linked from that.

* the author copies the SHA of the commit where the PR is actually pointing (let’s say: A)
* it resets the HEAD and fixes what’s needed (let’s say: B, C and D)
* pushes with force the new head of the PR (D)
* adds a comment in the PR (or directly in the commit message of B or D) referencing the reset commit (A)

This way one can see a clean pull request, but can also make sense of what changed and what previous comments are referring to, because it could go to the A commit and check its history.

I think it would be the cleaner approach.
Just my ignorance doesn’t let me know if the A commit and its history (till the common ancestor with B/C/D) would still be kept available or if there is the risk that a prune will remove the A commit and its eventual history because of not being referenced by any branch or tag…

Thanks for the suggestion Dominic. Squash-merging can sometimes work, but it can also be very problematic. I have just published a follow-up blog post which goes into much more detail on this: http://blog.adamspiers.org/2017/08/16/squash-merging-and-other-problems-with-github/

That’s a great suggestion Alberto, thanks 🙂

In this way the final view is a ordered list of comments from the author of the PR that describe the evolution of the code, and the reviewers can detect easily (via notification) that this change is in place.

For example:
https://github.com/crowbar/barclamp-nova_dashboard/pull/216

There are some noise, but basically you can see the evolution of the changes over time, without creating extra PR

Each pull request is tied to a unique branch in your fork, so yes if you want to pile more commits on top of an existing pull request and publish them without adding them to the pull request, you need to put them on a different branch.

Ok. So I checked-out the commit. Switched to a new branch, pushed it to the remote, then created a new pull request from the branch.

Crazy.

Is there a way to create a pull request at a specific commit hash, or must they always be fore wherever HEAD is?

Many times I came to a pull request which was after several rounds of reviews and updates in this style. Almost invariably, such a pull request was a big mess with commits on the main page scattered among comments which often lacked context (because they referred to code or comments that were no longer visible in the pull request). I could make sense of the whole thing only by reading a compete set of notification e-mails (if I had it), but there I often found broken links to obsolete diffs, so I still didn’t have the complete picture.

My ideal solution would be simple: Detect force-pushes on GitHub side and create a new version of the pull request each time (with a completely blank slate — just the title, description, and new set of commits). Link these versions together using next/previous links or some index. Then I’d be perfectly happy because the history and context in which comments and changes happened would be completely preserved.

As a side note, what you perceive as GitHub doing the right thing on history rewrites (hunks etc.) I always perceived as randomness. Sometimes comments were preserved, sometimes not, sometimes notification links worked after a force-push, sometimes they broke, etc. Sure, I knew there is some system behind this, but it never became obvious to me. And I know I’m not alone.

I have a very different view on this.

Actually I don’t think you do …

I was bitten by force-pushed changes to pull request just a few too many times. It makes it hard or sometimes even impossible to follow what actually happened. References will be missing or be wrong (e.g. the list of commits in the initial comment of the pull request). GitHub tries to make sense of it, but it simply can’t when the history is being rewritten.

Sure; did you read the paragraph where I wrote this, or the earlier blog post linked from it?

Now don’t get me wrong – GitHub is not perfect. In some (but not all) ways, it is inferior to Gerrit’s review system which is better at exposing the complete history of the review cycle. I previously wrote another blog post examining GitHub’s review system in more depth. But in general, it’s usually plenty good enough.

I already mentioned some of these issues there. However in practice I find it very rare that there are significant problems.

So I very much prefer to never change history, not even of transient pull requests. Pushing additional commits to a pull request actually can be quite nice, because as a reviewer you then see how what comments have been addressed. With a force push you basically have to always review the full change again.

As I already said, Gerrit handles this better (but Gerrit is horrible in other ways). But you have to admit there are also disadvantages to pushing additional commits, e.g. there is no way to view the effect of some squashed commits until they are actually squashed.

Usually it is a good idea to clean up after the review and create a polished version of the pull requests with squashed commits, fixed typos in commit messages, etc. I find it a nice way to simply create a new pull request with a cleaned up version of the commits and put in the number of the original pull request in the comment. This will magically create the cross-linking between the two requests.

That’s an interesting idea, which combats one of the biggest problems of the “push additional commits into the PR” approach, namely pollution of the history with a bunch of ugly fixup commits. However two PRs per topic also makes it quite a bit more heavyweight.

That is my favorite work flow. I’m sure there are seven or seventy more 😉

Exactly, and this flexibility is one of the joys of git (and GitHub).

So I very much prefer to never change history, not even of transient pull requests. Pushing additional commits to a pull request actually can be quite nice, because as a reviewer you then see how what comments have been addressed. With a force push you basically have to always review the full change again.

Usually it is a good idea to clean up after the review and create a polished version of the pull requests with squashed commits, fixed typos in commit messages, etc. I find it a nice way to simply create a new pull request with a cleaned up version of the commits and put in the number of the original pull request in the comment. This will magically create the cross-linking between the two requests.

That is my favorite work flow. I’m sure there are seven or seventy more 😉