On 2 April 2015 at 18:15, R. David Murray <rdmur...@bitdance.com> wrote: > On Thu, 02 Apr 2015 09:31:08 -0700, Guido van Rossum <gu...@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 _______________________________________________ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers
