On 2016-11-14 19:33, Eric A. Borisch wrote: > OK, so to be pedantic, instead of using the the GitHub "Squash and > merge" button (one click) committers are going to: > > 1) Go to their local (filesystem) copy of macports-ports > 2) git checkout -b dgsb-master master > 3) git pull git://github.com/dgsb/macports-ports.git > <http://github.com/dgsb/macports-ports.git> master (Or grab the patch > from GH and apply that?)
Another quick way that would also include rebasing onto the current origin/master (once again assuming "origin" is the remote pointing to macports/macports-ports): git checkout -b pull-XYZ origin/master curl -sLS https://github.com/macports/macports-ports/pull/XYZ.patch \ | git am > 4+) "squash and rebase magic command(s) here including Closes: #xx > verbiage" (Guessing this is might be two commands. One at a minimum.) > 5) git push origin master > > All without accidentally changing/committing/appropriate-git-verb-ing > any other local WIP changes. > > I like the one-click approach here, for obvious reasons. Yes, I'm sure > anyone can become adept at the steps above -- but I believe the > one-click approach will still be faster (I'll race you: aaaaaand done.) > and will have less potential user error. Assuming this (multi-step > process above) is the same workflow the S&M button automates for you > behind the scenes, I think it would be better in the long run to train > developers when to use squash+M vs. rebase+M, and let us leverage the > benefits of GH. 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 suppose the other option is to ask the submitter to resubmit this as > one change, and then use the Rebase & Merge button? The only reason I > still like the S&M button is that it lowers the barrier to > contributing... If we wanted to ask the submitter to resubmit, what is > the proper action to ask for? 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. Rainer [1] https://github.com/macports/macports-ports/pull/32
