Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> 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.
