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 <ba...@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)
_______________________________________________ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers