Re: [RFC/PATCH] log: add log.firstparent option

[Jeff King <peff@peff.net>]

On Fri, Jul 24, 2015 at 08:04:21AM -0700, Junio C Hamano wrote:

> > I think a really simple example is something like:
> >
> >   1. somebody implements as feature. It needs to handle cases a, b, and
> >      c, but it only handles case a. Therefore it is buggy.
> >
> >   2. During review, somebody notices case b, and a new commit is made to
> >      fix it. Nobody notices case c.
> >
> >   3. The topic is merged.
> >
> >   4. Much later, somebody notices the system is buggy and hunts in the
> >      history.
> [...]
> 
> I actually do not think the above is quite true.  In our kind of
> "clean history, we do not squash 1 & 2.  See Paul's "rewrite am in
> C" series, for example, that starts from a "buggy" (in the sense
> that it does almost nothing in the beginning and then gradually
> builds on).
> 
> Instead, even somebody did not have foresight to realize 'b' when
> she adds code to handle 'a', we would make sure the solution for 'a'
> is sufficiently clearly described in commit #1.

Sometimes. There's definitely human wisdom going into the decision to
squash or make a new commit, which is a good thing. Here's a
counter-example to the am series. When I wrote the object-freshening
code, I accidentally inverted the test for checking whether packs were
fresh. This was noticed in review, and I corrected it by inverting the
is_fresh function. But in doing so, I introduced a new bug, where the
test for loose objects was inverted.

The original fix was squashed in the re-roll, but much later we noticed
and diagnosed that new bug. It was very valuable to me to read the
mailing list archive to see what happened, because the fact that there
_was_ a bug fix was lost in the clean history.

-Peff