On 11 April 2017 at 13:13, Mariatta Wijaya <mariatta.wijaya@gmail.com> wrote:
"View Changes" doesn't work when commits in PR were squashed, which seems to be the case in https://github.com/python/cpython/pull/851
I wonder if there is a way to unsquash the commits? Will it help with reviewing this PR?
Mariatta Wijaya
On Tue, Apr 11, 2017 at 2:55 AM, Donald Stufft <donald@stufft.io> wrote:
If someone makes a review on github (as opposed to a simple comment) I believe the state of the code as it was when that review as made can be viewed by hitting the “View Changes” button next to that review in the timeline.
On Apr 10, 2017, at 3:18 PM, Guido van Rossum <guido@python.org> wrote:
Thanks for the clarification. We should probably move this discussion to the python-committers list rather than core-mentorship.
On Mon, Apr 10, 2017 at 12:12 PM, Terry Reedy <tjreedy@udel.edu> wrote:
On 4/10/2017 12:54 PM, Guido van Rossum wrote:
So the response from Martin Panter (https://github.com/python/cpython/pull/851#issuecomment-292755992) sounds like he's not set up for the new GitHub workflow. I'm CC'ing Martin here.
The specific issue Martin raised is "Sorry but I don’t have an easy way to see your fixes relative to the old version I reviewed." If the original and modified patches were posted in proper format to b.p.o., then one could hit [review] to start Rietveld and request a side-by-side diff of the two versions. This is perfect for reviewing responses to comments, especially those made in-line. For this issue, Martin made about 20 inline comments.
I don't see any way to get the equivalent on a github PR. It appears that the original patch is replaced by the revised patch. To me, Rietveld was a great review tool and its loss a regression in the work process. I hope that this can be fixed somehow.
In this particular pull request, I think the submitter has rebased their commit, and force-pushed it. These days, I notice Git Hub seems to forget old commits pretty soon after you force-push the branch they are on. I don't think you can "unsquash" them retrospectively; you would need a copy of the old commits saved somewhere.
Other times people add revised commits on top of their old commits, which would have been easier for me in this situation, but I suspect that makes it harder for the person pushing the final change if they have to squash it into a single commit. (I noticed the eventual commit message is often messy, redundant, automatically generated, etc.)