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.
pgpb7B5GSe0oA.pgp
Description: OpenPGP digital signature
_______________________________________________ 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