[python-committers] Do people prefer pushing feature repos or one massive patch?

Paul Moore p.f.moore at gmail.com
Thu Apr 2 22:13:26 CEST 2015


On 2 April 2015 at 18:15, R. David Murray <rdmurray at bitdance.com> wrote:
> On Thu, 02 Apr 2015 09:31:08 -0700, Guido van Rossum <guido at python.org> 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 feature or bug fix, they are often checkpoints with no particular
>> significance except that the code is syntactically correct, and a common
>> reason for doing a sub-commit is when I've got to attend to something else
>> (e.g. a meeting).
>
> I think a lot depends on the personal style of the committer.  I don't
> do checkpoint commits, but only (try to do) commits where everything
> works and the tests pass, and the commit is reviewable as a single unit.
> I don't think there's a right or wrong way to do this, I think it
> depends on how the person doing it thinks and organizes their work best.
> I don't see a lot of value in preserving the history of someone who uses
> the checkpoint-commit style, but I do see potential value in preserving
> the history of someone who uses the atomic-commit style.  Perhaps we
> should leave it up to the committer, based on that guideline?  (Given
> our other preferences, I think a rebased commit would be the way to go
> if history is preserved.)
>
> But, if we feel a need to pick just one, I'd pick squashed.

I tend to develop patches using Mercurial Queues, so I naturally
produce squashed commits. On the other hand, I very frequently do
checkpoint-style commits (sometimes even partially-completed work that
doesn't pass tests) because I move between 2 PCs, and keeping work in
progress just in the working directory isn't an option in that case.

Generally, I prefer squashed commits in any case.
Paul


More information about the python-committers mailing list