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....@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 <et...@stoneleaf.us> wrote:
> I like one massive patch, myself.  :)

Aye, I'm also in the "squash for the clean history" approach. 
_______________________________________________
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

Reply via email to