On 30 November 2015 at 03:12, Brett Cannon 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. 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) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On Nov 29, 2015, at 11:08 PM, Guido van Rossum wrote:

On Sun, Nov 29, 2015 at 7:54 PM, Nick Coghlan mailto:ncoghlan@gmail.com> wrote: On 30 November 2015 at 03:12, Brett Cannon mailto: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).

I don’t believe Github even has an option where you *have* to use the web-based merge process. The closest thing they have is protected branches (disables force pushes, but not regular pushes) and required status checks (PRs have to pass certain pre merge tests before the merge button lights up). Maybe the required status checks disables pushes all together but I don’t think it does and even if it did that feature (as currently implemented anyways) doesn’t make sense for us because it essentially requires all PRs to get rebased or have master merged into them before they can be merged via the merge button which is a massive pain for OSS teams of any size or velocity.

There are also tools like git-pulls (Ruby: https://github.com/schacon/git-pulls https://github.com/schacon/git-pulls) and hub (Go: https://hub.github.com/ 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/ 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.

I don’t know about Gitlab, but GitHub exposes PRs as heads in the remote repository. You have to add a single line to your .git/config in that repository, but once you do they are available to use any regular git command against (check them out, diff them, whatever). Doing that won’t get the comments on the PR and the pre merge test status and such of course, but someone can merge a PR just by doing (if configured): $ git merge upstream/pr/XXXX Here’s my configuration for the pip repository on GitHub that is configured in this way: https://bpaste.net/show/77b17a2571f0 https://bpaste.net/show/77b17a2571f0 Line #14 is the important part. This also makes my local master and develop branch track the upstream repository, while my own branches get pushed to my fork which is the origin remote. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

On Nov 29, 2015, at 11:31 PM, Donald Stufft wrote:

I don’t know about Gitlab, but GitHub exposes PRs as heads in the remote repository.

Yes, GitLab has essentially the same thing. I personally recommend fetching the merge request branch, and then switching to it locally via some name, e.g. $ git fetch https://gitlab.com/person/mailman.git branch-to-merge $ git checkout -b person/27 FETCH_HEAD Now I clean up the person/27 branch, maybe make more comments, rebase, etc. Once I'm happy with the branch, it's simple to $ git co master $ git merge person/27 $ git push I generally let it fast-forward merge if possible (which it usually is if I rebase). Cheers, -Barry

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 wrote:

On Sun, 29 Nov 2015 at 21:08 Guido van Rossum wrote:

...

On Sun, Nov 29, 2015 at 7:54 PM, Nick Coghlan wrote:

...

On 30 November 2015 at 03:12, Brett Cannon 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)

On Nov 29, 2015, at 08:08 PM, Guido van Rossum wrote:

What?! I've never worked with a GitHub-based project where you *had* to use the web-based merge process.

All GitLab merge requests have a button that pops up the commands you can copy and paste into your terminal to do a local, manual merge. There are several reasons why I'll do it that way: * I might want to clean up the branch a little bit and not bog the submitter down with style nits or whitespace issues. * I might have to add a NEWS entry. * I might want want run the test suite with a fix not applied, just to prove that the test actually exposes the problem. * I might want to manually rebase all those commits for cleaner history or easier cherry-picking to stable branches. OTOH, when something looks pretty clean, I'll just hit the auto-merge button, perhaps telling it to rebase first. I don't think there's anything special about GitLab here. Either GitHub has something similar, or it's just as easy to do via command line git if you can remember the incantations. Cheers, -Barry