[core-workflow] Questions about the proposed workflows

Barry Warsaw barry at python.org
Tue Dec 1 20:47:57 EST 2015


On Dec 01, 2015, at 11:24 PM, Brett Cannon wrote:

>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?

I think "merge turds" and intermediate commits are kind of two separate
things and GitLab makes some of what you want possible.

If you don't want a merge commit, you'll want a fast-forward merge, which
basically just moves the HEAD ref forward to the commit at the end of the
source branch.  This might require a rebase if the source branch is behind the
target branch.

With GitLab, under a project's settings, you have an option to only accept
fast-forward merges.  If you enable this, you get a second option to present a
rebase button on accepted merge proposals.  We could enable them both, and
this would allow (but not force) a merge proposal which applies cleanly
(e.g. no conflicts) to be rebased and then fast-forward merged through the web
into the target branch.  Thus, no merge commit.

However I think removing the intermediate commits require an interactive
rebase to squash commits on the source branch.  GitLab doesn't provide a
through-the-web interface to interactive rebases.  You'd have to use the
command line for this, and I often do that when I want to make local cleanups
to the source branch.

>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 think partly it depends on what we want.  I've thought we wanted a dedicated
VM, running a GitLab CE or EE instance, responding to git{,lab}.python.org.
But I don't know whether we want console/sudo access, we want to run our own
backups, whether that VM would be in our DC or theirs, etc.  Where does the
dial between completely hands-off to self-hosted point?

I've traded a few emails with the CEO of GitLab, who certainly seems eager to
help us, but we haven't sussed out any of these details.

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20151201/95062305/attachment.sig>


More information about the core-workflow mailing list