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 <[email protected]> wrote: > > > On Sun, 29 Nov 2015 at 21:08 Guido van Rossum <[email protected]> wrote: > >> On Sun, Nov 29, 2015 at 7:54 PM, Nick Coghlan <[email protected]> wrote: >> >>> On 30 November 2015 at 03:12, Brett Cannon <[email protected]> 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)
_______________________________________________ core-workflow mailing list [email protected] https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
