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

[Guido van Rossum]

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 at 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 at python.org
> https://mail.python.org/mailman/listinfo/python-committers
>



-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20150402/765ef787/attachment.html>