Hello folks, Google is hosting a standing engineering discussion about libifying Git, for contributors interested in participating in or hearing about the progress of this effort. Expect this discussion to be free-form and casual - no powerpoints here! We're hoping to hold this meeting every Thursday at 9:30am Pacific (16:30 UTC) via Google Meet. To get an invite to the video conference and the notes document, please reply to this email. Please also add points to the agenda (template follows) if you want to raise awareness of them. We'll choose a topic to discuss at the beginning of the meeting, and I'll reply afterwards with the notes. - (asynchronous) What's cooking in libification? - Patches we sent regarding libification - Patches for review related to the libification effort - (asynchronous) What happened in the past 1-2 weeks that interested parties or intermittent contributors need to know? - (asynchronous) Where are you stuck? What eng discussions do we want to have? (We'll choose a topic from this list at the beginning of the meeting.) - Session topic: <TBD> The notes from last week follow - my bad for not getting them out sooner. - What's cooking in libification? - Patches we sent regarding libification * Strbuf cleanups (all except patch 7/7 has been merged): https://lore.kernel.org/git/CAFySSZAOqX0pESfJ-7bYg9iR2RDB9PL6sC4Kcvr\_zitdQ1kD\_g@xxxxxxxxxxxxxx/T/ - Patches for review related to the libification effort - (asynchronous) What happened in the past 1-2 weeks that interested parties or intermittent contributors need to know? - Where are you stuck? What eng discussions do we want to have? (We'll choose a topic from this list at the beginning of the meeting.) * Calvin: cleaning up git-compat-util. Git-compat-util contains the following: * Includes for standard and external libraries * Includes for internal headers (wildmatch.h, banned.h) * Elijah: I've got a patch removing wildmatch.h - is Calvin already working on it? * Calvin: Nope, please send, this is out of scope of what I was looking at so happy to see your patch removing it * Declarations for functions in usage.c, wrapper.c, and various other files * Conditionally defined includes, functions, variables, macros * Unconditionally defined includes, functions, variables, macros * Some of the macros are for allocing arrays. Alloc.h also contains ALLOC\_GROW and ALLOC\_GROW\_BY. Should those macros be moved into a header file like alloc-ll.h or a common.h? I originally thought alloc-ll.h made a lot of sense, but then then are macros like COPY\_ARRAY and MOVE\_ARRAY that wouldn’t fit in there * Emily: Would these 4 macros make sense in something like array.h, instead of packed up with alloc? Does it help at all to separate this way instead? * Jonathan: Deciding how to slice it is pretty subjective, better to focus on what users need to include in order to use the libraries..? * But then, moving stuff from usage/wrapper into their own headers might be a good idea. * Better to focus on "we need to move it for $REASON" than for organizational purposes? * Randall: Historically, the purpose of git-compat-util.h is to allow all the platform-specific stuff to be in one place. If we're moving alloc stuff away from there, the alloc stuff is platform-specific, so it might add some complexity, right? * Calvin: alloc has #ifdef alloc\_h, i'd like to leave those platform-specific ifdef'd stuff in git-compat-util, but the unconditional platform-agnostic stuff might make more sense to stand alone and reduce the volume of git-compat-util. * Randall: Yes, having git-compat-util contain only platform-dependent things. * Elijah: banned.h is maybe an exception, because it's required everywhere just like git-compat-util is…? * Calvin: see point below about git-common-header.h * I want to lessen the scope of git-compat-util to the following * Includes for standard and external libraries * Conditionally defined includes, functions, variables, macros * Unconditionally defined includes that are directly used by conditional includes can still be left in here * Which means the other items belong in different files. I propose: * common.h * Unconditionally defined includes, functions, variables, macros * usage.h, wrapper.h, etc. * Declarations for functions in usage.c, wrapper.c, and various other files * git-common-header.h * #include "git-compat-util.h" * #include "usage.h" * #include "common.h" * #include "wrapper.h" * #include "banned.h" * This will be included by all files instead of git-compat-util.h (or we could and move git-compat-util.h to a different file and rename this file to git-compat-util.h) * Elijah: is wrapper.h/usage.h really needed by everyone? Otherwise LGTM * Calvin: usage.h doesn't quite exist, proposing to create it and start to remove it * Jonathan: usage.h also has die() * Emily: +1 * Elijah: next series is basically ready to send, no more cache.h >:) moves all the header decls into relevant files instead, so there's nothing left. * …and there was much rejoicing * Emily: Josh Steadmon will be joining us working on unit testing into CI etc, looking forward to it * Randall: Can share how we run Git suite on NonStop if that's helpful, since any libification stuff needs to work there * Emily: Good idea to take a look at Calvin's c-tap-harness RFC, seems like platform compatibility will be a decision point about how to make sure unit tests are working on "exotic" platforms * https://lore.kernel.org/git/20230427175007.902278-1-calvinwan@xxxxxxxxxx/ * Elijah: For c-tap-harness, if the unit tests are quite small, then outputting "test OK" for every test becomes a performance bottleneck. Are we batching those test plan outputs somehow? Some other performance thing? * Emily: benefit of having a source fork is that we can fix it * Randall: c-tap-harness uses autoconf that's beyond what NonStop can support. Major issue for NonStop on other projects * Elijah: but if we're bringing it in as a source dep then we don't use autoconf and we can just build it with make, right? * Randall: also isn't it in cpp? Will we be able to use it? * Calvin: I compiled it as C in the RFC so I think we will be ok * Randall: oh, yeah, it's C89 so it will be OK for us since we guarantee C99 * Calvin: no fork up on GH or something, but you should be able to apply those rfc patches to master and try it out
