Re: How to substructure rewrites?

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 27, 2014, 15:58 UTC
Message-ID: <xmqqppndpgbg.fsf@gitster.dls.corp.google.com>
In-Reply-To: <877g9ocjsk.fsf@fencepost.gnu.org>

David Kastrup <dak@gnu.org> writes:

Show 18 quoted lines

> As it can easily be guessed, the "add xxx function" commits are
> basically adding not-yet-used code (and so will not disrupt
> compilation), but everything starting with "Reorganize blame data
> structures" up until the final commit will not work or compile since the
> code does not match the data structures.
>
> So there is little point in substructing all that, right?  Even
> something seemingly isolated like
>
> commit f64b41c472442ae9971321fe8f62c3885ba4d8b7
> Author: David Kastrup <dak@gnu.org>
> Date:   Sun Jan 19 02:16:21 2014 +0100
>
>     blame.c: Let output determine MORE_THAN_ONE_PATH more efficiently
>
> is not really useful as a separate commit since while it does implement
> a particular task, this is done starting with non-working code relying
> on no-longer existent data structures.

Small pieces that are incrementally added with their own documentation would certainly be a lot easier to read than one big ball of wax. I am wondering if it would make it easier for everybody to tentatively do "git-blame vs git-blame2" dance here, just like we did "git-blame vs git-annotate" dance some years ago. That is, to add a completely new command and have them in parallel while cooking in 'next' (or we could even keep them in a few releases if we are not absolutely certain about the correctness of the result of the new code), aiming to eventually retire the current implementation and replace it with the new one. We have already have test infrastructure to allow us to run variants of blames, too, to help that kind of transition.

> In general, the rule is likely "any commit should not create a
> non-working state" right?

Yes.