[core-workflow] Questions about the proposed workflows

[Donald Stufft]

For Github, Yes and No.

You can have status checks which will either prevent the merge, or will color it yellow to indicate that it shouldn’t be merged (but will still allow it). Unfortunately right now the implementation of preventing the merge unless all status checks pass ALSO makes it so that you cannot have any commits on the branch you’re merging into that are not contained within the PR. The practical implications of this is that anytime you merge a PR or push commits to master (or another branch), all PRs to that branch need to be rebased or have master merged back into them. They do provide a “Update Branch” button to do this automatically if there are no conflicts, however you only get that button if you have write permission to the incoming repository (e.g. if I fork python/cpython to dstufft/python and make a PR, you’d need write permission to dstufft/cpython to get that button). This makes mandatory checks pretty useless for most OSS projects.

> On Dec 13, 2015, at 5:53 PM, Brett Cannon <brett at python.org> wrote:
> 
> 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 <mailto: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 <mailto:donald at stufft.io>> wrote:
> 
> > On Dec 13, 2015, at 7:55 AM, Christian Heimes <christian at python.org <mailto: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 <mailto: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 <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
> 


-----------------
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/a1b33034/attachment.html>
-------------- 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/a1b33034/attachment.sig>