On 2 April 2015 at 22:06, Jason R. Coombs jaraco@jaraco.com wrote:
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.
Having a feature repo to *work* on a patch is a great idea, I interpreted the question as being about what the mainline history should look like. The latter is where I strongly prefer the "atomic feature commit" model.
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia