Re: [PATCH v2 00/24] Header cleanups (splitting up cache.h)

>
> On Wed, Apr 5, 2023 at 10:30 AM Calvin Wan <calvinwan@google.com> wrote:
> >
> > "Elijah Newren via GitGitGadget" <gitgitgadget@gmail.com> writes:
> > > This series builds on en/header-cleanup
> > > (https://lore.kernel.org/git/pull.1485.v2.git.1677197376.gitgitgadget@gmail.com/)
> > > and en/header-split-cleanup
> > > (https://lore.kernel.org/git/pull.1493.v2.git.1679379968.gitgitgadget@gmail.com/),
> > > and continues to focus on splitting declarations from cache.h to separate
> > > headers. This series continues dropping the number of cache.h includes; in
> > > this series we go from 254 such includes to 190.
> > >
> > > The series may appear to be long at first glance, but is repetitive and
> > > simple. It should be relatively easy to review, and falls into roughly 3
> > > categories. An overview:
> > >
> > >  * Patches 1-6, 7: Being more explicit about dependencies. This was
> > >    motivated by the fact that trying to find unnecessary dependencies on
> > >    cache.h were being made harder by implicit dependencies on trace.h,
> > >    trace2.h, and advice.h that were included via cache.h. (Similar to
> > >    gettext.h handling in the previous series.) So I simply try to make
> > >    dependencies more explicit, for both these headers and a few others. To
> > >    make review easy, I split it into half a dozen patches, one header per
> > >    patch (well, except that I handle trace.h and trace2.h together). Patch 7
> > >    then removes several includes of cache.h that are no longer needed due to
> > >    patches 1-6.
> > >  * Patches 8-19: For several choices of FOO, move declarations of functions
> > >    for FOO.c from cache.h to FOO.h. To simplify reviewing, each case is
> > >    split into two patches, with the second patch cleaning up unnecessary
> > >    includes of cache.h in other source files.
> > >  * Patches 20-24: Other small manual cleanups noticed while doing above work
> > >
> > > Since patches 1-15 & 17-19 are just more of the same types of patches
> > > already reviewed in the last two series, it probably makes more sense for
> > > reviewers to focus on the other patches: 16 + 20-24 (which also happen to be
> > > smaller). I would particularly most like review of patches 16, 22, & 24
> > > since they are the least like any previously reviewed patches.
> >
> > Patches 1-15 a& 17-19 LGTM! Very welcome changes to see the size of
> > cache.h shrink after this and your previous series.
> >
> > I had the same change in patch 16 on a local branch, specifically moving
> > editor related functions from strbuf. The eventual dream for lower level
> > libraries such as strbuf is to separate out the functions that touch
> > higher level objects, allowing for the eventual libification of parts of
> > Git.
> >
> > Patch 20: removal of unnecessary headers are always welcome since it
> > allows readers to easily understand what dependencies a file has.
> >
> > Patch 21: I do have a suggestion that I will leave on the patch
> >
> > Patch 22: with what's currently in wrapper.h, it feels like it's
> > becoming the new dumping ground for functions that don't quite have a
> > home elsewhere. While I think this change makes sense right now, I do
> > hope in the future wrapper.h can be broken up with more reasonable
> > boundaries rather than "this function is a git-specific stdlib or
> > whatever lib function".
>
> Yeah, I wouldn't be surprised that we have multiple places needing
> cleanup.  I haven't looked much at wrapper.[ch] from this angle, but
> you got me curious and I took a brief glance.  Do you really mean
> wrapper.h, or wrapper.c?  wrapper.h is actually pretty small, only
> declaring 8 functions.  The other 32 non-static functions in wrapper.c
> are declared in git-compat-util.h.
>
> > Patch 23: same reasoning as with patch 20, swapping to more precise
> > headers clarifies file dependencies
> >
> > Patch 24: moving more items from the "dumping ground" to where they're
> > supposed to be :)
> >
> > Besides patch 21, the rest of the series LGTM, thanks!
>
> Thanks for taking a look!