The notes from today's session follow. - (asynchronous) What's cooking in libification? - Patches we sent regarding libification - Coccinelle conventions https://lore.kernel.org/git/pull.1495.git.git.1681329955.gitgitgadget@xxxxxxxxx - Patches for review related to the libification effort - cache.h cleanups https://lore.kernel.org/git/pull.1509.v2.git.1680571348.gitgitgadget@xxxxxxxxx - (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> * Elijah: I have the next set of cache.h cleanups waiting around, but I'm waiting for the first set to make it in, and wondering whether I should rebase onto Calvin * Calvin: you should send yours without waiting, I don't think there will be a conflict * Elijah: ok, will try to avoid strbuf and git-compat-util changes * Glen: Hey take a look at https://lore.kernel.org/git/pull.1495.git.git.1681329955.gitgitgadget@xxxxxxxxx * Elijah: I also wasn't sure how to review these, the how-to sounds useful but I don't know any better either? * Glen: If this series doesn't seem to make your life easier, then it hasn't achieved its purpose * Should this come with MyFirstSemanticPatch..? * General approval 🙂 * Maybe it can come later * Calvin: We've been working on the idea of a "git-std-lib" internally * Libification of "just strbuf" and "just hashmap" vs. libification of "all the shared low-level stuff that depends on each other" * Removing the dependency on wrapper.h/usage.h is really tricky * So instead, a standard library which is includable from git library callers and also used throughout Git's own codebase * Stuff like strbuf, string\_list, abspath, strmap, strvec, wrapper, usage, utf8, etc etc etc all in a single library * To get the proof of concept, made some cleanups to git-compat-util, removed dependencies on repository.h, trace2.h, etc were refactored or replaced with a stub in the unit test makefile * Have something promising internally * Does this seem like a good idea..? Hoping to send RFC after OOO next week sometime * Elijah: Expecting lots of people to ask what's the purpose of the standard library, does it imply backwards compatibility, etc etc * No backwards compatibility, if consumers want to accept that churn then they can use it with no promises * Emily: In fact, it's likely to start out pretty rough, with still prints and dies and so on, so we will intend to change it a lot afterwards * Calvin: You might ask, why not do that first? Mostly, to unblock others as quickly as possible 🙂 If we can make it possible to build something on top of it and prove it's usable, then that gives us more momentum to keep polishing it * Randall: Do we want to mark these apis as experimental? * Emily: Yes, this and all the apis we're working on for the foreseeable future * Elijah: static? Dynamic? * Calvin: static for now. I don't have a lot of experience with Makefile * Where are these makefile changes going? * Emily: Early stages, we want to make a guarantee about the ability to compile and unit test, that's likely to go into t/Makefile * Glen: Maybe later it makes sense to move things into lib/ and stand up a lib/Makefile, but we can cross that bridge when we come to it * Randall: atexit() is used in Git, be careful with deps on atexit() in a dynamic library please! It's not very platform consistent * Emily: Randall, can you take one of these sessions and tell us all the stories about atexit() 🙂 * Elijah: hash.h depending on repository.h, stringmap depending on hash.h, this is gross. But FYI I did work on something to remove repository.h from hash.h * Calvin: we ran into that problem, yeah. Very cool to hear you have some fix, can we see it 🙂 * Elijah: mempool? * Calvin: not worried about mempool * Elijah: Was doing some performance testing moving functions into a new file and determining if it was helpful or not (to see if I can replace rust stuff) * Turns out there's a small performance degradation moving something into a new file like this? * We might be able to use this to increase performance in some places too * Calvin: do we know why? * Elijah: maybe code locality..? It's a function that's being passed to qsort, so it was being run in a very tight loop, it seems like that difference in cache locality made a difference * Jonathan: I've seen this kind of thing as an argument to be pro-C++ because templates mean you can choose this functionality at compile time and avoid this penalty. * Elijah: I spent a lot of time on microoptimizations for the merge code, it was difficult to parallelize it as it is (in C/++). Why not 🦀? Was an interesting experiment to look into performance regressions. Putting the sort into rust actually gave some speedup. Being able to optimize that sort was really helpful. * Randall: Other compilers, like Intel C99, the optimizer can do some things with comparators in the same object as the qsort invocation to avoid that penalty. * Randall: Happy to talk about C multithreading too, look over code, etc * Randall: Have been pressed into service as CVE analysis manager. Thinking about the libification project and tests as a very good thing for tracking down CVEs in the base code (if they lurk there). Being able to test libraries on their own is really helpful from there, thanks! On Tue, Apr 11, 2023 at 11:40 AM Emily Shaffer <nasamuffin@xxxxxxxxxx> wrote: > > 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 a day ahead of the > meeting.) > - Session topic: <TBD>
