On 2 April 2015 at 18:15, R. David Murray <rdmurray@bitdance.com> wrote:
On Thu, 02 Apr 2015 09:31:08 -0700, Guido van Rossum <guido@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