[core-workflow] Questions about the proposed workflows

[Donald Stufft]

> On Dec 13, 2015, at 7:55 AM, Christian Heimes <christian at python.org> wrote:
> 
> 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

I actually prefer non-ff merges, but that’s something that’s going to be very opinion driven (to ff or not to ff). Obviously going with GitHub is (at least currently) choosing to go with non-ff most of the time.

-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151213/3e9fcd52/attachment-0001.sig>