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 <br...@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 <don...@stufft.io> wrote: > >> >> > On Dec 13, 2015, at 7:55 AM, Christian Heimes <christ...@python.org> >> wrote: >> > >> > On 2015-12-02 00:32, Donald Stufft wrote: >> >> >> >>> On Dec 1, 2015, at 6:24 PM, 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. >> >> >> >> 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 >> >>
_______________________________________________ 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
