On Mon, Nov 14, 2016 at 1:17 PM, Rainer Müller <[email protected]> wrote:
> I agree this is not the easiest workflow we could have. However, even > with "Squash and merge" button, you could only replace 4) and 5) of your > steps with the web interface. You still need to the other steps to test > the changes anyway. I had already tested (applied in one line with patch and curl, because those I know how to use them) the change. It would still be less error prone at that point to have the S&M button. As proof, look no further than what actually ended up happening on this PR [1] during this discussion. As a wish list item, It would be awesome to have an automated build that would run at least through the checksum phase for PRs with just version # and checksum changes. > It is cumbersome to ask the pull request author to go through with this. > I recently made the same experience [1], but explaining how to edit the > pull request properly definitely took longer than just fixing it myself. > > I am not opposed to enabling "Squash and merge", but we have no guide > for maintainers explaining the pull request workflow. If we had this, it > could explain the differences between the "Rebase and merge" and "Squash > and merge" button and when to use what. > Well, I vote for some education (guide section) plus enabling the squash and merge button. [1] https://github.com/macports/macports-ports/pull/37#issuecomment-260430808 - Eric
