On 2 December 2015 at 09:24, Brett Cannon <br...@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.
GitLab Enterprise Edition has a fast-forward-only merge option that disallows merge commits on the target branch: http://doc.gitlab.com/ee/workflow/ff_merge.html That then further enables rebasing of merge requests via the browser: http://doc.gitlab.com/ee/workflow/rebase_before_merge.html > The GitLab-specific question is what, if anything, is GitLab prepared to > offer us? Both Nick and Barry have hinted that GitLab would host us, listen > to our needs, etc., but it has always seemed to be speculation. Do we have > concrete information as to what GitLab is willing to do for us? I'll leave answering that to Barry, since he's the one that's actually been talking to the GitLab folks :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
