When I said intermediate merges, I meant additional detail like "fix typos and remove dead code" in this PR to asyncio: https://github.com/python/asyncio/pull/290/commits . And I don't like to see merge turds like these in my history (we've experimented with this a bunch in the asyncio repo):

*   b516e80 Merge pull request #231 from haypo/issue_222
|\
| * b08ee40 Fix @coroutine for functions without __name__
* |   cd10ff2 Merge pull request #237 from ajdavis/update-queue-join-tests
|\ \
| * | 70d8856 Fix queue join tests for CPython's test runner.
|/ /
* |   bcb7ec4 Merge pull request #236 from ajdavis/queue-join-fix
|\ \
| * | e496c7c Fix LifoQueue's and PriorityQueue's put() and task_done().
| * | a943b49 Test LifoQueue's and PriorityQueue's put() and task_done().
|/ /
* | 7718675 #230: Change official URL from tulip to asyncio in README.rst
|/
* 173ff86 Update README.rst
*   4f9099e Merge pull request #225 from Eyepea/add_pycharm_in_gitignore
|\
| * 30f4788 add in .gitignore pyvenv and Pycharm files
|/
*   3582e11 Merge pull request #224 from Eyepea/readme_improvement
|\
| * bf4b2ce Rename README file to have rst render on Github
* | 1888b1d Switch hgignore and hgeol to git equivalents
|/

But of course I would love a web-based merge flow that doesn't create such turds! (It must be possible, since I can do it manually. :-)

Also, AFAIK git keeps separate track of who authored a change and who committed it, so credit to contributors should still be maintainable.

On Sun, Nov 29, 2015 at 8:54 PM, Brett Cannon <brett@python.org> wrote:

On Sun, 29 Nov 2015 at 21:08 Guido van Rossum <guido@python.org> wrote:
On Sun, Nov 29, 2015 at 7:54 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 30 November 2015 at 03:12, Brett Cannon <brett@python.org> wrote:
> Thanks for the feedback. And the "do nothing" option is there, although it's
> so disliked by so many people that the chances of us not changing our
> workflow is pretty slim.

The interests of folks that prefer the terminal focused
"commit-locally-and-push" workflow can still be taken into account in
the evaluation though - while it appears likely either GitHub or
GitLab will be adopted as the repository management service, whether
or not the maintenance branches and the default branch are marked as
protected so even core developers *have* to go through the web based
merge process is a separate question.

What?! I've never worked with a GitHub-based project where you *had* to use the web-based merge process. Hopefully that's not really on the table. In fact I'm not a big fan of GitHub's web-based merge process at all -- I much prefer seeing a simple linear history in the master (and I don't like preserving intermediate commits made during the PR review process).

Donald addressed the protected branch bits, but the web-based PR merging will be discussed as a possible allowed workflow. It doesn't have to be settled now but just so you know my position, I like the web-based merging as it means I don't have to worry about being on a machine with a repo and SSH keys in order to do a merge (e.g., I could do a merge from my Chromebook while on vacation or at work on my lunch break without issue). I also don't mind the intermediate merges as it gives contributors proper attribution for their work (you can use I believe `git log --merges` to only see git merge logs which would be written by core devs).

-Brett

There are also tools like git-pulls (Ruby:
https://github.com/schacon/git-pulls) and hub (Go:
https://hub.github.com/) that let folks review and merge GitHub PRs
from the terminal. (I had a quick look through some of the command
line clients listed at https://about.gitlab.com/applications/, but
didn't see anything as workflow focused as git-pulls or hub, so "good
support for terminal based usage" may count as a concrete technical
differentiator here)

Review and merge process should be separable. After 10+ years of using web-based review tools I personally wouldn't dream of using a terminal-based *review* (as opposed to merge) process. Though of course if that's your preference you should be able to do it.

--
--Guido van Rossum (python.org/~guido)

--Guido van Rossum (python.org/~guido)