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

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 24, 2015, 15:04 UTC
Message-ID: <xmqqd1zhoave.fsf@gitster.dls.corp.google.com>
In-Reply-To: <20150724073415.GD2111@peff.net>

Jeff King <peff@peff.net> writes:

Show 29 quoted lines

> 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.
>
> In a "clean" history, the patches from steps 1 and 2 are squashed. While
> reading the history, you see only "implement feature X", and no mention
> of the bug and its fix. But even if the person writes a terrible commit
> message for step (2), even seeing it pulled out into its own diff shows
> the exact nature of the already-seen bug, and may make it more obvious
> to realize that case (c) is a problem.
>
> I realize that's kind of vague. Another way to think about it is: in a
> squashing workflow like git.git, any time you have to turn to the
> mailing list to read the original sequence of re-rolls, you would have
> been better off if that information were in git. That's a minority case,
> but I certainly have turned to it (in some cases, the "fix" from our
> step 2 above actually introduces the new bug, and it's nice to see the
> reasoning that went into it :) ).
>
> Not that I am advocating for git.git to move to such a workflow.

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.

In other words, without #1 and #2 squashed together, the history you presented in your example _could_ be already "clean". It just boils down to the quality of individual commit.