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)