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).

On Thu, Apr 2, 2015 at 6:31 AM, Barry Warsaw <barry@python.org> wrote:

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, further hiding potential problems.

In general I agree. Coming from bzr, it's very rare that merges get rebased
first, but bzr has a strong "mainline-of-development" view that tends to make
squash-before-merge unnecessary. diffs, bisects, logs, etc generally follow
first-parents by default so you don't see all the subcommits, unless you want
to, which sometimes you do.

git doesn't really follow this tradition (although some commands have an
option to follow first parents). Not sure about hg.

Cheers,
-Barry

_______________________________________________
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers

--Guido van Rossum (python.org/~guido)