Re: [PATCH v2 0/8] hook API: connect hooks to the TTY again, fixes a v2.36.0 regression

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

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

> The current proposal is large by line count, but it's relatively easy to
> skim it and assure oneself that a new parameter is being passed in, and
> that all the proposed behavior change applies only to the one caller
> that passes in that new parameter.
>
> Whereas switching to a new non-callback based API will require carefully
> going over the parallel API line-by-line, assuring oneself that the
> non-callback version is really doing the same thing etc.

I was worried about something like that when I wrote (admittedly
unfairly, in a somewhat frustrated state) that the series was
designed to be hard to revert.  The reverting itself was reasonably
easy if the "did we invoke the hook, really?" topic is discarded at
the same time, but if was done with too much rearchitecting, it is
understandable to become cumbersome to review X-<.

I wonder if rebuilding from scratch is easier to review, then?  The
first three patches of such a series would be

 - Revert cb3b3974 (Merge branch 'ab/racy-hooks', 2022-03-30)
 - Revert 7431379a (Merge branch 'ab/racy-hooks', 2022-03-16)
 - Revert c70bc338 (Merge branch 'ab/config-based-hooks-2', 2022-02-09)

and then the rest would rebuild what used to be in the original
series on top.  There will be a lot of duplicate patches between
that "the rest" and the patches in the original series (e.g. I would
imagine that the resulting hook.h would look more or less
identical), but "git range-diff" may be able to trim it down by
comparing between "the rest" and "c70bc338^..c70bc338^2" (aka
ab/config-based-hooks-2).  I dunno.

Thanks.