Re: How to substructure rewrites?

[Junio C Hamano <gitster@pobox.com>]

David Kastrup <dak@gnu.org> writes:

> 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.