[core-workflow] Questions about the proposed workflows

[Christian Heimes]

On 2015-12-02 00:32, Donald Stufft wrote:
> 
>> On Dec 1, 2015, at 6:24 PM, Brett Cannon <brett at python.org> wrote:
>>
>> It's Dec 1, which means it's time for any questions people have about the proposed workflows so we can get answers by Dec 15.
>>
>> I have one question that applies to both proposals and one specific to GitLab. The general one is whether both Guido and me can both be happy. :) Guido doesn't want intermediate commits nor what he calls "merge turds" to show up in the history. I want to be able to do merges from the browser. Do either GitHub or GitLab provide a way through the web UI to give Guido what he wants, or will it always require having a checkout and SSH keys set up in order to do a PR merge? If only Guido can be made happy then that means either proposal becomes an easy way for people to get code hosting for their forks and a review tool but not a PR management platform since merges would occur outside the website and merges would simply be a `git push` which is basically what we do now to do the final merge for a patch.
> 
> As far as I am aware, when you merge with the browser in GitHub it essentially does ``git merge —no-ff`` which means there will *always* be a merge commit. There’s no support for a rebase workflow (where you rebase the branch ontop of master) or for squash merges or for FF merges.

Merge commits are the single most idiotic feature in GitHub because
GitHub enforces non fast-forward merges. Merge commits bloat and clutter
the revision history with useless junk, e.g.
http://ariya.ofilabs.com/2013/09/fast-forward-git-merge.html . We either
have to live with the fact that CPython's revision history is going to
contain lots of superfluous checkins or we cannot use the green merge
button at all. By the way it is not possible to disable or hide the
merge button. This means that we have to teach all committers to resist
the temptation and do a manual merge.

GitHub claims that non-ff merges are superior because they add context
information to merges. The same can be accomplished with mandatory links
to tickets and Reviewed-by, Tested-by and Signed-off-by lines.

I'm -1 on GitHub as long as GitHub doesn't support fast-forward merges.

Christian