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.
O
On Apr 02, 2015, at 12:06 PM, Jason R. Coombs wrote:
>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, furthe
On 04/02/2015 07:38 AM, Nick Coghlan wrote:
> On 2 April 2015 at 05:05, Matthias Klose wrote:
>> We'll have the 2.7.10 release in the coming months. This will be the first
>> release with a two digit subminor version number, so please could we prepare
>> for
>> that early? Feature tests in pytho
Where I come from we always squash. More detailed history is preserved in
the code review tool (which keeps a snapshot every time you bounce it back
to the reviewer). Looking at my own sub-commits when I'm working on a
complex feature or bug fix, they are often checkpoints with no particular
signif
On Thu, 02 Apr 2015 09:31:08 -0700, Guido van Rossum wrote:
> Where I come from we always squash. More detailed history is preserved in
> the code review tool (which keeps a snapshot every time you bounce it back
> to the reviewer). Looking at my own sub-commits when I'm working on a
> complex fea
On 2 April 2015 at 18:15, R. David Murray wrote:
> On Thu, 02 Apr 2015 09:31:08 -0700, Guido van Rossum wrote:
>> Where I come from we always squash. More detailed history is preserved in
>> the code review tool (which keeps a snapshot every time you bounce it back
>> to the reviewer). Looking at
