[core-workflow] Questions about the proposed workflows

[Barry Warsaw]

On Dec 13, 2015, at 01:55 PM, Christian Heimes 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.

Coming from Bazaar, I was used to non-ff merges.  One thing commit merges
allows, which works well with bzr's strong main-line-of-development view of
the world[1] is that log and bisect feel more natural.  Meaning that when you
need to bisect to find a problem, or want to see mainline changes, you
generally won't see the branch author's intermediate commits.  But sometimes
you *do* want to dive into those sideline commits and of course there are
options that allow you to do so.

But the more I use git, and once I understood what they do to the graph, the
more I've come to like fast-forward merges, and on projects I host on GitLab,
I like having the ability to allow ff-merges.  Doing this through the web ui
usually requires rebasing though, either automatically (and GL has an option
to allow rebase-before-ff-merge) or manually by the original branch author.
The linear history is pretty nice.

There are a couple of trade-offs though.  If the rebase or merge doesn't
squash commits, then it's possible for a bisect to land inside an intermediate
commit, and if those intermediate commits don't always pass the test suite
then bisect will see test failures, which could make bisect more difficult to
use.

Also, in practice, I usually have to do *some* clean up of submitted branches
anyway (e.g. whitespace or add NEWS), so the choices are; 1) locally branch,
cleanup, test, rebase, ff-merge, push; 2) cleanup locally after automerging;
3) insist that the cleanups be done by the original author before the merge is
approved.  I've found #1 to be the least work for drive-by contributions, but
for core-contributor branches in Python, #3 will probably be more common and
then we might miss ff-merges more.

So bottom line, I like the *option* of ff-merging and it can often be the
cleanest way to move history forward.  At least with GL, you still have the
option of doing a merge commit when that's what you want.

Cheers,
-Barry

[1] which I'd argue correlates strongly to most project's reality, and is one
thing I miss in git.  Of course, with merge commits, you have `git log
--first-parent` although I'm not aware of a similar ability with bisect.
-------------- 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/20151213/a9c02cb8/attachment.sig>