[core-workflow] Questions about the proposed workflows

[Brett Cannon]

And couldn't we have a pre-merge web hook that always rejected merges
through the browser if we chose to?

On Sun, 13 Dec 2015, 14:31 Brett Cannon <brett at python.org> wrote:

> Berker also said a bot could do the ff workflow which could also handle
> the NEWS problem as well as long term branches. Assuming that's true and we
> choose to solve those problems that way then it will be true on either
> platform.
>
> On Sun, 13 Dec 2015, 05:39 Donald Stufft <donald at stufft.io> wrote:
>
>>
>> > 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 --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151213/15534074/attachment-0001.html>