On Mon, Nov 14, 2016 at 11:36 AM, Rainer Müller <rai...@macports.org> wrote:
> On 2016-11-14 18:11, Eric A. Borisch wrote: > > If squash-and-merge is what we're going to want for pull requests, can > > we re-enable the button? (Also known as, if we're using GitHub, can we > > use GitHub?) Ideally contributions from others (like this pull request) > > should be as painless (read as: fewest steps that still achieve the > > desired ends) as possible on both sides. > > In the migration, we were reluctant to enable "Squash and merge", as it > would be the default option when enabled. GitHub does not allow to > select a different default. Developers without Git/GitHub experience > (and there seem to be quite a few) might be tempted to just press the > default button. As there was a consensus to keep the history mostly > linear [1], "Rebase and merge" was the best compromise as default, which > is only achievable by disabling the other options. > > Maintainers should checkout the pull request to test the changes, so > they can also squash and rebase the commits locally and then push the > result. Just remember to add the appropriate "Closes: #xx" to the commit > message, so GitHub can properly attribute the change. > > Rainer > > [1] https://trac.macports.org/wiki/WorkingWithGit#Rebasing > 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 master (Or grab the patch from GH and apply that?) 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 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? Thanks, - Eric
