I'm in the other camp.
The way I see it, a squash of history or massive patch file loses history. It loses details about the thought process of the implementer. It masks mistakes and obscures motivations. It also masks decisions made in the merge operation, further hiding potential problems.
On the other hand, a feature repo (or any separate series of commits), while retaining the history as it happened and thus the fidelity of the development, can always be mechanically reduced to a squashed patch (for review or other considerations, and in fact, the Python bug tracker will produce these squashed patches from feature repos automatically even if they're hosted in another system). Rollback is trivially easy; reverting a merge is as easy as reverting a squashed commit. It has the added benefit that any individual commit can be backed out automatically (in a squashed patch, that's not possible).
In other words, it's straightforward and easy to go from the latter model to the former, and generally impossible to reverse the operation.
In my opinion, it boils down to whether the group wants to restrict the options available for review. I would recommend that a contributor provide (or maintain) a feature repo if convenient.
-----Original Message----- From: python-committers [mailto:python-committers-bounces+jaraco=jaraco.com@python.org] On Behalf Of Nick Coghlan Sent: Thursday, 02 April, 2015 01:35 To: python-committers Subject: Re: [python-committers] Do people prefer pushing feature repos or one massive patch?
On 2 April 2015 at 04:09, Ethan Furman <ethan@stoneleaf.us> wrote:
I like one massive patch, myself. :)
Aye, I'm also in the "squash for the clean history" approach.