[core-workflow] Questions about the proposed workflows

[Nick Coghlan]

On 13 December 2015 at 22:55, Christian Heimes <christian at python.org> wrote:
> 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.

GitLab actually have a useful page discussing some of the trade-offs
of different git workflows:
http://doc.gitlab.com/ee/workflow/gitlab_flow.html

One of the points they make regarding "no commits to master, only
merges" is that it means that regardless of whether you're working on
a simple change that can be handled on a single commit, or a
multi-commit feature branch, there will always be a single merge
commit at the end, and that's what you revert if you decide to back
out the change - you never need to ask the question "Are there
multiple commits I need to revert in order to back that change out?".

Given GitHub (and GitLab's) origins in the continuous
integration/continuous deployment world of network service
development, it's easy to see how that's an attractive feature: when
committing to master triggers an automated deployment, you want the
rollback code to be able to automatically step back to the right place
if the initial deployments in a phased rollout indicate a bad update.

That's potentially useful to us as well, since we'll likely keep
cross-platform testing on the BuildBot fleet as a post-commit
activity, and use something easier to scale (like Travis CI) for
pre-commit testing.

If we were to adopt the "commit to master and backport" model for
maintenance branches, then filtering out merge commits to master
should also eliminate most of the clutter from "git log", while still
presenting the meaningful changes to each branch.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia