Message ID | 20230516170932.1358685-1-calvinwan@google.com (mailing list archive) |
---|---|
Headers | show |
Series | git-compat-util cleanups | expand |
Calvin Wan <calvinwan@google.com> 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 <gitster@pobox.com> 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