<div dir="ltr"><div><div><div>That's all fine (and I still prefer GitHub), but in the mypy I recently saw a log like this:<br>```<br>* 7c9b2a6 Merge branch 'xxx-xxx'<br>|\ <br>| * c833d7e Tweak test case<br>| * e52f2ff Fix crash<br>| * ccca8c1 Add tests for #1234<br>| * e870d0c Fix #1234<br>|/ <br>*<br>```<br></div>This is clearly just some local development commits -- the entire thing should have been a single commit labeled 'Fix #1234' (and perhaps a better description of how or what). I guess we could request contributors to squash the commits in the PR. But that's definitely adding extra work for most contributors (and may add a day to the commit cycle if they've already gone to bed or off to work or play). I can do all this manually on the command line, but the convenience of the Merge button is pretty high...<br><br></div>TBH the argument from being able to roll back things doesn't feel very strong at Dropbox. We use a merge process where developers' commits are always squashed into a single commit in master once code review is finished (we have command-line tools for this based on Phabricator's Arcanist). And of course we also have to roll back stuff. But I've never heard of a problem where we had to roll back multiple commits to get back into a reasonable state.<br><br>Of course there are long-running projects that are committed to master in many smaller pieces. But we take care that ever partial commit is tested properly and we have a dynamic database of feature flags that we can use to turn features on or off per user or group of users so we can alpha-test committed code with select groups of users (usually Dropbox employees are the first guinea pigs :-). Rolling back multiple commits feels like it would be precarious -- most likely there would be merge conflicts with other code that came in between (a lot of people typically work on the same modules and packages).<br><br></div>Python development feels different -- fewer committers, fewer commits. I'm willing to live with history like I quoted above just to have the convenience of using the GitHub PR process, which many potential contributors have already experienced.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 14, 2015 at 3:16 AM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 13 December 2015 at 22:55, Christian Heimes <<a href="mailto:christian@python.org">christian@python.org</a>> wrote:<br>
> Merge commits are the single most idiotic feature in GitHub because<br>
> GitHub enforces non fast-forward merges. Merge commits bloat and clutter<br>
> the revision history with useless junk, e.g.<br>
> <a href="http://ariya.ofilabs.com/2013/09/fast-forward-git-merge.html" rel="noreferrer" target="_blank">http://ariya.ofilabs.com/2013/09/fast-forward-git-merge.html</a> . We either<br>
> have to live with the fact that CPython's revision history is going to<br>
> contain lots of superfluous checkins or we cannot use the green merge<br>
> button at all. By the way it is not possible to disable or hide the<br>
> merge button. This means that we have to teach all committers to resist<br>
> the temptation and do a manual merge.<br>
><br>
> GitHub claims that non-ff merges are superior because they add context<br>
> information to merges. The same can be accomplished with mandatory links<br>
> to tickets and Reviewed-by, Tested-by and Signed-off-by lines.<br>
><br>
> I'm -1 on GitHub as long as GitHub doesn't support fast-forward merges.<br>
<br>
</span>GitLab actually have a useful page discussing some of the trade-offs<br>
of different git workflows:<br>
<a href="http://doc.gitlab.com/ee/workflow/gitlab_flow.html" rel="noreferrer" target="_blank">http://doc.gitlab.com/ee/workflow/gitlab_flow.html</a><br>
<br>
One of the points they make regarding "no commits to master, only<br>
merges" is that it means that regardless of whether you're working on<br>
a simple change that can be handled on a single commit, or a<br>
multi-commit feature branch, there will always be a single merge<br>
commit at the end, and that's what you revert if you decide to back<br>
out the change - you never need to ask the question "Are there<br>
multiple commits I need to revert in order to back that change out?".<br>
<br>
Given GitHub (and GitLab's) origins in the continuous<br>
integration/continuous deployment world of network service<br>
development, it's easy to see how that's an attractive feature: when<br>
committing to master triggers an automated deployment, you want the<br>
rollback code to be able to automatically step back to the right place<br>
if the initial deployments in a phased rollout indicate a bad update.<br>
<br>
That's potentially useful to us as well, since we'll likely keep<br>
cross-platform testing on the BuildBot fleet as a post-commit<br>
activity, and use something easier to scale (like Travis CI) for<br>
pre-commit testing.<br>
<br>
If we were to adopt the "commit to master and backport" model for<br>
maintenance branches, then filtering out merge commits to master<br>
should also eliminate most of the clutter from "git log", while still<br>
presenting the meaningful changes to each branch.<br>
<span class="im HOEnZb"><br>
Cheers,<br>
Nick.<br>
<br>
--<br>
Nick Coghlan | <a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a> | Brisbane, Australia<br>
</span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
core-workflow mailing list<br>
<a href="mailto:core-workflow@python.org">core-workflow@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/core-workflow" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/core-workflow</a><br>
This list is governed by the PSF Code of Conduct: <a href="https://www.python.org/psf/codeofconduct" rel="noreferrer" target="_blank">https://www.python.org/psf/codeofconduct</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div>