On 2 April 2015 at 22:06, Jason R. Coombs <jar...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers
