Re: [PATCH 0/6] git-compat-util cleanups

Calvin Wan [off-list ref] writes:

This series focuses on cleaning up and reducing the scope of
git-compat-util.h by moving headers to their respective files and
separating out functionality from git-compat-util.h to a new file,
common.h. I go into more detail in patch 3 as to why I believe this
separation is useful. 

By the end of this series, git-compat-util.h includes common.h which
includes wrapper.h and usage.h. Since virtually every file includes
git-compat-util.h and the large majority of files use functions defined
in common.h, wrapper.h, and usage.h, I believe it makes sense that those
are also automatically included with git-compat-util.h.

While this series does not intend to draw clearer boundaries for
common.h, I am open to ideas for how it can be cleaned up more and if
there is a better name for the file. 

This seems to have been based on 'master' around Apr 25th of this
year, like 0807e578 (Merge branch 'en/header-split-cache-h',
2023-04-25).  If this were written some time ago and have been
tested internally at $WORK or something, *not* rebasing on a later
tip of 'master' (which you did) is good, but at the same time, it
would be nice to hear on which commit the series is designed to be
applied.  To prepare for the start of the next cycle, however, it
may be even better to rebase it on the tip of more recent 'master'
and test it internally (again), and sending the result out as v2
would very much be appreciated ;-)

Thanks.

On Tue, May 16, 2023 at 10:54 AM Junio C Hamano [off-list ref] wrote:

This seems to have been based on 'master' around Apr 25th of this
year, like 0807e578 (Merge branch 'en/header-split-cache-h',
2023-04-25).  If this were written some time ago and have been
tested internally at $WORK or something, *not* rebasing on a later
tip of 'master' (which you did) is good, but at the same time, it
would be nice to hear on which commit the series is designed to be
applied.  To prepare for the start of the next cycle, however, it
may be even better to rebase it on the tip of more recent 'master'
and test it internally (again), and sending the result out as v2
would very much be appreciated ;-)

ok I'll go ahead and do that